View source for ChucK/Features/Release

== [[ChucK]] Wish List for New Release ==


=== Wishes that are still open/ under debate ===


1.2.1.1
* Extend maybe to include possibly (25%) maybe (50%) & probably (75%) (from [[ChucK/Features/Main]]) '''(ge: interesting...  is (maybe&&maybe) and (maybe||maybe) not expressive enough?)''' 
::(I love those and will use them but I found that audiences think Maybe is funny so there is some merrit to these sugestions. Also; they can't hurt(Kas))
* multiple public classes per file ([[User:Scott.Wheeler|Scott.Wheeler]] 10:29, 8 August 2007 (EDT))
: '''(ge: there are plans to adopt a java-esque auto dependency finding system, and thus limiting things to a single public class per file. perhaps we should re-evaluate this?)'''
:: (sounds good, why not share what the plans are at this point on the list so we can talk about those and see wether they cover everybody's needs? (Kas) )
::: The only reason that I feel like that works in Java is because of the concept of jars, which still allow you to pack things into functional bundles.  I'm not sure how that would play out on the file system.  The main concern for me is, i.e. being able to pull in all of my MIDI related classes in one go without having to list 10 files on the command line, but also to mix those with ChucK snippets in other places in my directory hierarchy. (Sidenote -- perhaps others should also use mediawiki threading like I've done here?) [[User:Scott.Wheeler|Scott.Wheeler]] 11:28, 15 August 2007 (EDT)
::::Thanks, didn't know the proper way, fixed.
* Make MIDI more friendly, using named functions instead of numbers like was done with the HID, as discussed (Kas).
:: perhaps this would also be a nice moment to add MIDI clock, this has been requested many times by many people.
* Look into the current state of chuck --shell's code replacement and update functionality so that the (mini)Audicle can provide a graphical interface to this and we can update just a section of a shred, leaving the rest be, SC-style.(Kas)
* A way to record to one stereo file, as opposed to two mono ones(kas). and hopefully to a n-channel file also ([[User:Kijjaz|kijjaz]])
* Merge ASIO into main build (and the mini, and the audicle....)(kas)
* Some way to poll the OS for the current time (of the day)(Kas).
* A way to use Array of Float to store and manipulate digital sound signal easier..
(for example, copy-paste, loading-saving (like SndBuf and WvIn/WvOut), Reading-Writing (and interpolation) (kijjaz) ::(sounds a bit like a list to me, I'd like lists for that purpose but I have Prolog-induced brain damage(kas) )The more I think about this the more it apeals to me. How hard would it be to have a sort of SndBuf that gets asigned a list of floats to play/loop over while keeping that list editable? Alternately, can we overload SndBuf.read() to accept chucking arrays of floats directly to it, thus turning those into it's buffer?
::This seems covered nicely by the planned changes to LiSa
* More LPF, HPF, BPF, BRF filter types and configuration, I know this is going to be implemented soon anyway,
the vintage-sounding Moog low-pass filter (kijjaz) 
* Data and Text file input/output (kijjaz) 
::Yes! preferably in combination with string-management and the ability  to load data types like arrays from files, this sounds complicated but it will open the door to things like machine-written scores and so on... (Kas)
::Please, please. I know ChucK is very oriented towards live/interactive use, but it would be very powerful if the data and algorithm spaces could be separated such as in CSound. This way a single program could operate on any number of compositions. Possibly, the i/o could handle MIDI files eventually as well. I see today (21 Oct 2007) on the forum that someone has implemented their own file i/o scheme which shows how desperate some people are for it! (chuckles)
* Easier console communication methods (for example, more printing and input ways) (kijjaz)
* Extend ZeroX to also behave as a event that can be chucked to now. This will enable us to perform operations such as gain changes glitch free without a expensive loop with a samp as it's control-rate.(Kas)
::Probably covered by a planned UAna? Zerocrossing detection was on the planned list for those.
* Hid-out for force-feedback in joypads or simply blinking the num-lock/capslock/scrolllock lights to the beat; if we can borrow from Choo-Choo-Rocket we can borrow from Rez (Kas)
* New UGen: for calculating '''Min'''imum and '''Max'''imum of all the inputs. ([[User:Kijjaz|kijjaz]]) (Huh? What D'ya mean? ([[User:Gasten|Gasten]]))
::I think like you can ChucK multiple Ugens into a single gain where it multiplies or adds but instead here this Ugen would only output the highes or lowest one ([[User:Kassen|Kassen]]))
* Public events! Public events would be kick ass! (Gasten)
::You can have public events by making them a static part of a public class. That way all instances of that class will share the same event. Maybe not a permanent solution but it's workable(Kas)
* serial input/output capability for arduino(arduino.cc) and wiring support...
* spork ~ somefunc(); should have it's own namespace when ID's is assigned. Problem: If you got a shred that's sporking new child-shreds once or twice every second (for example: on every noteOn), we'll pretty soon have shred-id's in the 300+-spectrum. If we, at the same time, are experimenting with adding shreds via otf-commands, it'll pretty easily get out of hand (eg: hi hat on 314, bass on 52, melody at 11 and the kick at 184). Part of the problem is that the next shred-id is the highest shred +1, and not the highest unassigned shred. Solution: We can assign child-shreds to the parent's namespace like this: xx.yyy (if xx is the parent's id, and yyy is the child's id), ie if shred 11 sporks a new child shred, it gets the name 11.001, next get 11.002, etc. Of course, we could end up having id's like this: 11.012.001.005. (Gasten)
* More things to be treated as objects so they can be referenced, assigned and so on. (see also; [http://electro-music.com/forum/viewtopic.php?t=23546], [http://electro-music.com/forum/topic-23628.html] and [http://electro-music.com/forum/viewtopic.php?t=24874] ) Could be a big issue with matching repercussions. Likely needs debate. (EM-ChucK-society ;¬) )
* enter text here, discuss directly on page here, thanks!

===Things that were implemented ===
New in 1.2.0.1
* FFT support '''(ge: done and will be in 1.2.0.9)'''
* Complex Number support, or is this available now together with FFT support soon? (kijjaz) '''(ge: yes! done and will be in 1.2.0.9)'''
* Control for the volume of each of LiSa's voices, I believe Dan was going to do that but it can't hurt to repeat that I'd realy like it. (Kas) '''(dt: done; readme-LiSa2.ck has doc)'''
* Consider a non-0 default frequency for Resonz as debated on the list on May22(Kas).'''it's in 1.2.1.0'''