dewdrop_world
AdminGroup
Full Member
Karma: 9
Posts: 193
|
 |
« Reply #1 on: April 29, 2006, 09:14:04 AM » |
|
Sure, no problem. It's a bit of a change in that in the functionality is split out into different objects now, but I find this allows more flexibility because they can be recombined in different ways.
CCResponder is the recommended basic way to get MIDI controller data into SuperCollider. Details are in the MIDIResponder help file. In the responder, you will define an action function that will be executed whenever a matching MIDI message comes in. This function is where you will update the GUI and map the MIDI data onto a synth control value.
GUIs expect a range of 0..1 when you update the value. That's an easy conversion: incoming value / 127.
ControlSpec is the way to map 0..1 onto any other range. It behaves a lot like minval/maxval in the sc2 GUIs.
Here's a quick example.
c = ControlSpec(20, 20000, \exp); // map 0..1 onto frequency: \freq.asSpec will get you the same thing r = CCResponder({ |src, chan, num, val| val = val / 127; mySynth.set(\modwheel, c.map(val)); { mySlider.value = val }.defer; // defer is necessary for GUI updates }, nil, nil, 1); // values after the function are a filter to restrict the action to a specific set of MIDI ports, channels, controller numbers and even values. This will match the mod wheel on any input.
My class extension library, available on my web site, has a lot of MIDI convenience classes. Most important is Voicer and VoicerMIDISocket, which together provide similar functionality to the sc2 Voicer object. Let me know if you have specific questions about any of those objects.
Hope this helps-- hjh
|