Hi, list. At the moment I'm merrily ChucKing allong building a little "groovebox". My idea here is that it's easier to put knobs on a laptop then it is to put a comand line on a groovebox. The plan is to have one shred backed by a few sporked functions that will allow me to manipulate data in arrays using a midi controler (toggeling steps for beats, so far). Eventually this will use events to trigger the sounds in other shreds so those sounds could be re-compiled without ruining the data in the arrays. This is working nicely and seems like a good idea, even if at the moment it's not quite up to the level of a rs7000 or Live (yet!). For true groovebox functionality it would be nice to have some way of listening to a MIDI clock and this seems to be missing at the moment. Of cource MIDI sync normally works quite differently from the typical structure of ChucK code but at least some way of relating to it would be nice. I'd like to sugest some new function for this. What if we had something that would for example be able to output those midi clock "sync" pulses (I think they are properly defined as repeat "play" messages or something along those lines?) as events as well as the duration (in time) between the last two clock ticks of a incoming clock. Practically speaking it might be more sensible to average the time of -say- the last four of those, considdering how inacurate MIDI is and how quickly multiplied jitter might add up if looped. This would enable us to have chuck loops that would go something like; //wait for next sync event sync => now; //main loop while(true) { something_involving_realy_cool_beats; //advance my sequencer 1 +=> steps; (steps % 16) => steps; //advance time by a quarter note 24::click => now; } Now; this example would probably start drifting unless the duration of "click" was updated frequently by some external loop (thus averaging out the jitter) and even then some more advanced form of syncing the whole loop up every once in while would be preferable, especially if the external master clock will be modulated in mid piece.... Still; I hope this demonstrates that Chuck programs could relate to a MIDI clock in a way that's at least somewhat similar to the way they normally relate to the internal ChucK "now". Bad; Keeps MIDI alive while it realy should have died long ago. Good; Allows one to jam with friends who haven't yet realised MIDI should have been left in the 80's. Not all that complicated to implement, I imagine. Alternatively it would also be welcome to point me at where it says we allready have something like this; I looked and couldn't find a thing. Yours, Kas.
Hi Kassen!
At the moment I'm merrily ChucKing allong building a little "groovebox". My idea here is that it's easier to put knobs on a laptop then it is to put a comand line on a groovebox.
Awesome!
For true groovebox functionality it would be nice to have some way of listening to a MIDI clock and this seems to be missing at the moment. Of cource MIDI sync normally works quite differently from the typical structure of ChucK code but at least some way of relating to it would be nice.
Indeed there is no underlying functionality to interpret a MIDI clock at the current time. If we can work it cleanly into the timing framework it would certainly be worth having. It is now on the TODO list. Thanks for the suggestion and the potential solution!
Bad; Keeps MIDI alive while it realy should have died long ago.
Yes, in all likelihood, MIDI will outlive humanity.
Good; Allows one to jam with friends who haven't yet realised MIDI should have been left in the 80's.
Woohoo!!! Best, Ge!
Ge;
Indeed there is no underlying functionality to interpret a MIDI clock at the current time. If we can work it cleanly into the timing framework it would certainly be worth having. It is now on the TODO list.
Yeah, the "cleanly" bit might be a bit of a issue here. Compensation for latency to the MIDI clock like Live uses might not be possible in Chuck. Still, even being able to extract the time between clock pulses would be valuable for paterned effects and so on. Very few implementations get it right. Stricktly speaking the clock is just one byte and it's one that should be able to interupt other messages, then have those continue yet not all implementations do that. Oh, and I have another matter; Considder this little fragement; if (msg.data2==60) !patern[0] => patern[0]; if (msg.data2==62) !patern[1] => patern[1]; if (msg.data2==64) !patern[2] => patern[2]; etc. This refers to white key midi notes toggeling bits in a array called "patern" which holds ones and zeros which in turn represent my steps. (So I can do "if(patern[step]) 0=> buf.pos;" which I personally found rather elegant) This works perfectly fine but I couldn't find active use of the "!" operator documented anywhere. Checks involving it are all around but nothing like this active usage (as far as I could see) while this is quite handy. I figured it out by simply trying but it might be nice to have it documented somewhere. Yours, Kas.
In the original MIDI, clock was just a one byte message that subdivided musical time into either 12ths of 24ths of quarter notes. That, combined with MIDI start and stop, allowed drum machines to talk to each other and sequencers, etc. It should be easy to implement this using our standard MIDI and event framework: 0 => int device; // number of the device to open (see: chuck --probe) MidiIn min; // the midi event MidiMsg msg; // the message for retrieving data if( !min.open( device ) ) me.exit(); // open the device spork ~ handleMIDI(); fun void handleMIDI() { while (1) { min => now; // wait on the event 'min' while( min.recv(msg) ) // get the message(s) { if (msg.data1 == 248) { // MIDI Clock // Do clocky stuff, count to 24, determine delta-now, whatever } } }
On 4/21/06, Perry R Cook
In the original MIDI, clock was just a one byte message that subdivided musical time into either 12ths of 24ths of quarter notes. That, combined with MIDI start and stop, allowed drum machines to talk to each other and sequencers, etc. It should be easy to implement this using our standard MIDI and event framework:
Sure, that would work for me. Wait for one of those messages, store "now", wait for the next, store the new now. Substract those two, chuck the result to "dur click" and my example code would run already, in essense. We could average them out depending on wether long-term smoothness or a fast reaction to clock modulations would be preferable. It's simple, it's consistent and syncing to drum machines will open the way for lots of jokes about "crash cymbals". I like it. One thing that has me a little woried is that currently incoming MIDI messages can be depended on to be three bytes. Clock messages aren't so if we are going to have this then from then on sorting MIDI notes and cc's will need to be done starting with the first byte because otherwise trying to build conditions on what msg.data2 or msg.data3 are is going to cause trouble since they won't be there. This might break existing code. Not the end of the world and your idea is certainly both more simple and more consistend then my own proposal. Yours, Kas.
On Thu, 2006-04-20 at 14:39 -0400, Ge Wang wrote:
Hi Kassen!
At the moment I'm merrily ChucKing allong building a little "groovebox". My idea here is that it's easier to put knobs on a laptop then it is to put a comand line on a groovebox.
Awesome!
For true groovebox functionality it would be nice to have some way of listening to a MIDI clock and this seems to be missing at the moment. Of cource MIDI sync normally works quite differently from the typical structure of ChucK code but at least some way of relating to it would be nice.
Indeed there is no underlying functionality to interpret a MIDI clock at the current time. If we can work it cleanly into the timing framework it would certainly be worth having. It is now on the TODO list.
There is another timing source that would be very nice to have - JACK transport. When a timebase master is present in the JACK graph, all JACK clients are able to get the current bar, beat, tick, ticks per beat, BPM, and beats per bar at the beginning of each new JACK period. From that information it's also easy to determine at which exact frames the beats and ticks happen, and where new bars begin. Knowing the JACK transport BPM would be interesting for things like tempo-synced echos and LFOs, and knowing where the beat and bar boundaries are could be nice for things like sequencers and phrase triggers. -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E
participants (4)
-
Ge Wang -
Kassen -
Lars Luthman -
Perry R Cook