signal.automatique at gmail.com
Sat Apr 21 22:46:48 CEST 2012
On Sat, Apr 21, 2012 at 09:45:40PM +0200, pce wrote:
> On Fri, 2012-04-20 at 01:45 +0200, Kassen wrote:
> > quite inspired by devices for which MIDI clock is the only option
> Should the library work as a tight clock, something like a LAN Audio
> Sync Protocol?
I'd like it if one could conveniently get something like that out of
the library, yes. Music is a diverse thing, as are languages and it's
not the be all end all, but being able to get "pulses" at every 16th
note and a "reset" at the end of the pattern can be a simple joy.
> a side note:
> 96 PPQN (something like 96 ticks each Step) was a widespread Standard of
> MIDI Sequencer Ticks and 24 PPQN is used by MIDI Clock and that steals a
> lot bandwidth theoretically.
Yes, you are right. A lot of the traditional MIDI sequencers also work
with a higher internal representation than what they send,
interpolating if they are receiving.
> If i have at least a 96 PPQN Sync Protocol that only sends and receives
> BPM Changes (or X repeats to interpolate ticks from mid-points of
> the Packet Results List), is that not acceptable?
Yes, it would be. Actually we could base something like that on any
sufficiently advanced syncing protocol. My remark wasn't so much about
what I'd like from this as it was about how if MIDI clock would be
sufficient I see no reason to not simply use it, particularly not
because that also enbles sync with a lot of non-laptop musicians.
I also think that protocols that are more simple to set up and use
will have a higher chance of gaining wide-spread acceptance. I think
that's relevant because aside from the interesting technical issues
there is the social factor; we'd like to play together with our
friends and maybe make new friends through music. That, for all its
shortcommings, is certainly a strength of MIDI.
> Could "Client doubling as Server" fit for the desired features?
I think that yes, that makes sense. That would -to me- also hint at a
implementation using a separate program. I don't know what you guys
use and how stable it is, but my stuff tends to get stuck or crash at
times, mostly due to typos by me. It'd be nice if the serving musician
could also freely experiment and wouldn't need to stick to
conservative techniques out of fear of stopping everyone's clock.
Another bonus would be that that will probably decrease the need for
relatively low-level programming to implement it all in various
More information about the eightycolumn