Re: [Octal-dev] let's write the plugins we deserve

[Dave O'Toole]

Neil Nelson wrote:
> 
> You are already planning to have control signal channels as requested by
> Avelino.  It only remains to have a plugin generate a `beat' signal
> parallel

What I was talking about was just an auxiliary audio input for vocoding.
It sounds like what you are looking for is a non-continuous sort of
event input/trigger socket or some such. There might be a way to put
pulses/triggers in an audio signal and essentially run a peak detector
to figure out the correct time to do something. This would avoid
breaking the current block-gen model but sounds like a hack. That is,
nothing in the current API would prevent you from doing this, if you
really feel like encoding tracker data into an audio signal, but it's
not a very good idea. 

Don't some trackers have note-delay/offset functions for when these
off-the-wall rhythms are really needed? 

> or timing control plugin and signal might be in order so that a general
> method could be used by all affected (beat controlled) plugins.

If I understand you correctly we would in essence be implementing a
whole new timing mechanism and event scheduler on top of the existing
tracker-style one. Is this really a good idea? 

> Additionally, you were mentioning that the number of samples in a plugin
> processing block could be user selected.  Currently, it would appear that

Probably not. The block size is not the same as the tick size, and the
blocksize varies over time to adjust to global tick boundaries. 

> machines in general will have the same block size, though it
> would be fairly easy to connect machines all with different arbitrary
> block lengths and then merely point to the next machine in connected
> sequence, instead of a rigid matrix structure.  This would require some

I'm not sure exactly what you are saying. Are you talking about modeling
machine connections as a linked list? A directed graph organizes the
routing of signals between machines in Octal. You cannot reduce this to
a linked list. Whether or not we use a matrix or a linked representation
for this directed graph is not relevant, though if you really want to
get away from the matrix approach I am already planning to change this
(it's trivial and doesn't affect anything else but is probably cleaner.) 

> Buffering may slow down the throughput rate considerably depending on
> the degree of necessary timing mismatch between machines in the same

It's a given that for arbitrary block-sizes to work this way, the block
ends need to line up at some point. So let's imagine we have a
tick-length of 22 samples (I am trying to keep the number small, I know
this isn't realistic.) We want to play three-against-two. Machine A
plays two notes, machine B plays three. We divide 22/2 to get 11 samples
per sub-note for machine A. We divide 22/3 to get a blocksize of 7 for
machine B. Unfortunately, since these are both prime numbers, the
block-ends won't line up for 77 samples. That's more than three whole
ticks of latency and that example is only for TWO machines. I think
you'd need to take the LCM of all the different blocksizes. The latency
would be unacceptable in some situations. This is just more complex than
is needed, all to make it easier to do bizarre rhythm patterns. 

Plus, what do we do with the leftover 1 sample for machine B? 

> sequence having different block sizes and two mono machines going into
> a stereo machine that would then require synchronization, through buf-
> fering, of three machines.

> than we would want to go in the short term, but the current Octal
> arrangement can be seen as a specific instance included in the prior
> case.  I.e., it would be easy to maintain backward compatibility for
> the current arrangement while considering more general possibilities.

That's fine but it would still be a much larger, more complex, and
possibly more buggy timing engine whose only advantage relative to the
current scheme is that it allows some rarely used/obscure/weird
patterns. Why would this be so great? The simpler version will do 95% of
what is needed because in reality not much music really puts
7-against-5. The existing architecture already supports odd time
signatures so the scope of what is being left out is quite small. That
is important if you are entering Chopin into the computer (he often uses
such things) but nobody would think of using a tracker for this. This is
what MIDI is for. 


-- 
@@@ david o'toole
@@@ address@hidden
@@@ www.gnu.org/software/octal