[Fluxus] MIDI clock

[Kassen]

On 9 December 2010 13:06, gabor papp <gabor.lists at mndl.hu> wrote:

> thanks for the explanation Kassen.


You're welcome.

so do you think we also need some functions to enter this information to
> fluxus-midi? what would be a logical way to do this which relates well to
> music theory and how midi devices work?
>
>
First of all; I'd say that a repeated start message should be used to reset
the clock. That will make sure we can sync to the start of the pattern. This
will mimic the functioning of groove-boxes and the like which will by far be
the most common usage. It will also make the whole thing more robust in case
of missed messages. After all; MIDI lacks any kind of error correction.

Secondly; we need two modulo functions. One to section the pulses into
"beats" (quarter notes, sixteenth, etc) and another to section the beats
into bars. These are already there in Greg's plan, just hard-coded to
quarter notes and 4 beats per bar.

These 2 numbers could be set as global variables, if we'd like.

Personally I'm now leaning towards just handing the data to the user. That
way inline modulo functions could be used like with Fluxa. The advantage
there is that one part of the animation could react to straight quarter
notes while another part could respond to triplets, etc. That's more
versatile and closer to Fluxa. On top of that users could build a utility
function that would work exactly like Greg's plan if they'd like. We could
even supply that convenience function with the global variables as a utility
with the distribution.

That way both straightforward fun with house music and outlandish
experiments in math-rock would be possible, as easily as either is going to
be and we're not throwing away any of our precious data. I feel that it's
important to note that we can go from having all the data available to
utility functions for convenience but the other way around isn't possible.
It is of course also important that making nice visuals to straightforward
music is nice and straightforward.

Does that make sense? Does anyone spot concerns that aren't yet addressed
now? I think we can do it in a way that will make everyone happy.

Yours,
Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pawfal.org/pipermail/fluxus-pawfal.org/attachments/20101209/a838d6f8/attachment.html>