I need some additional MIDI features in ChucK for my application. I've
already added code to support a MidiOut.progchange(channel,patch)
method. Before I get too far along, I thought it would be a good idea to
compare notes with the ChucK developers and see what the future plans
are for MIDI support.
I see in the Wiki the following note about features being debated for
the next version:
"Make MIDI more friendly, using named functions instead of numbers like
was done with the HID, as discussed (Kas)"
Also in the "Ongoing Feature Request" page:
"Turn MIDI .msg parsing into a system of functions like was done with
the HID (".isNoteOn()", ".isControlerChange()", etc) especially with a
eye towards future incorporation of clock mesages and so on."
This is basically where I'm going to. Initially I needed the
progchange() function but I noticed while implementing it that a lot of
this functionality is already present in the lower levels of ChucK (e.g.
midiio_rtmidi.cpp and rtmidi.cpp). All I had to do was complete some
work that was mostly done in the low level files and then add the
progchange() method in chuck_lang.cpp.
I think it would be easy enough to add other functions that appear to
already existing lower down like polypress(), pitchblend(),
allnotesoff(), noteon(), noteoff(), etc.
I don't need all of that for my app but would be happy to continue
working on it if it's something that's needed by other ChucK users. But
if I do that, it would be nice to get some feedback on what method names
the dev folks would prefer to see used in the ChucK VM. On the other
hand, if this work is already under way by someone else, I don't want to
step on any toes or release a patch with conflicting MIDI methods. Any
thoughts on the best way to proceed?
-Steve
http://www.ncc.com/humans/srainwater
Fellow chuckists,
Today there were some posts on the forum here;
http://electro-music.com/forum/viewtopic.php?t=36259
about compiling ChucK on Fedora. It looks like the default configuration
doesn't work (anymore, I really think it used to) on that platform, at least
not without tweaking the optimisation. This could well mean that GCC was
again updated with more strictness. Fortunately steevithak was able to
document the cause and provide a workaround (see link).
This might be worth some attention, I think Fedora is quite agressive about
getting new things in (they are at GCC 4.4.0 while I've got 4.3.3 here as
part of the default stable Ubuntu release) so this may well be a advance
warning for the issues more Linux users are going to get once other distro's
switch to a newer GCC; for a fair percentage of Linux users ChucK will be
the first time they have to use GCC.
Yours,
Kas.
