PLAN B analog blog

having trouble syncing the tap clock to external sources (e.g. analogue solutions oberkorn 
sequencer) via the phase lock... it always seems to go slowly in and out of sync. quite a nice 
effect actually, but not necessarily the desired one.

anyone...?

Running the risk of sounding like a smartass...

It's not a problem...it's a feature???

Phil Gallo and I have spent many hours working on this, and we did
improve it since the prototype by doubling the speed of the crystal
that drives the micro, but the bottom line is in order to upscale, the
processor has to determine the interval of the base frequency between
incoming triggers and it needs to take system cycles to do that. 
That's what you're experiencing and these are the pitfalls of a
mutliply by 2 and 3 function when dealing with realtime events.

The interval is the same as what it's receiving, it just lags behind a
few steps.  This is why the input is called 'Phase lock' and not
'external clock'

My suggestion:  use the M28 as the master clock.  Run the Oberkorn
from it.

Phil and I are looking into an expander for the m28 - a simple analog
clock to midi clock converter so that external midi devices can be
synced easily to the goings-on of the M28.




--- In PLAN_B_analog_blog@yahoogroups.com, "michaeltritter"
<mtritter@...> wrote:
>
> 
> having trouble syncing the tap clock to external sources (e.g.
analogue solutions oberkorn 
> sequencer) via the phase lock... it always seems to go slowly in and
out of sync. quite a nice 

> effect actually, but not necessarily the desired one.
> 
> anyone...?
>

A little background on how the M28 operates: 

I need you all to go to Figure 1 on the  M28 page on the EAR site. 
Here's a direct link:

http://www.ear-group.net/28_tt.jpg

Of particular interest is the signal "Intap" 

Take notice to this signal. Intap is not part of the 2051 command set, it's put into play by the M28's program code. You'll notice there are 24 Intaps between each external clock (or tap) cycle. This number is significant as it's the lowest denominator required for generating 50% duty cycle quarter notes, eight notes and eight note triplets in real time.

In order to upscale the input frequency, the micro goes down a line of
instructions before sent to its main loop.  When the first tap (or ext. clock) is received, the processor tags the count of timer internal to the 2051 processor and counts the number of those cycles generated until the next tap (or ext. clock) is received.  It stores that number and uses it to adjust the frequency of Intap.

Once the processor sets the frequency of the Intap it then jumps into
it's main loop, which are timed by Intap.  Each of those 24 cycles
cycles are assigned a number of tasks (use figure 1 as a reference).
For instance,  the forth cycle changes the state of eight triplet 1
from high to low.  The sixth cycle does the same to the eight note 1.
 The 11th cycle is a busy one - it changes the state of the quarter
note (high to low), eight note number 2 (low to high) and triplet 2
(high to low). THis is how 50% duty cycle is achieved for each of the
the event strings. Along wth this there are other commands assigned to
all phases, even those which have no significance to the output
states. For instance, the the processor is constantly monitoring
itself to assure it's running correctly.  If it trips up, there are
routines to handle that, to pull it back into proper operation o the
quick (in short, we don't want your modules crashing on you.

This all makes sense, but what happens when your input frequency
doesn't evenly divide by the internal timer that used to set the
period of Intap?  We've got code to handle that as well -
but...there's a certain point where you have to make a decision how
many decimal places are you going to deal with, because the longer you
take to set Intap, the more behind you're going to get tp the outside
world.  Too many, you fall behind.  Too little, your Intap resolution
is inadequate.  There's a balance.  We tested many ratios before we
determined which handled these two extremes the best.

- P


--- In PLAN_B_analog_blog@yahoogroups.com, "(i think you can figure
that out)" <peter@...> wrote:

>
> Running the risk of sounding like a smartass...
> 
> It's not a problem...it's a feature???
> 
> Phil Gallo and I have spent many hours working on this, and we did
> improve it since the prototype by doubling the speed of the crystal
> that drives the micro, but the bottom line is in order to upscale, the
> processor has to determine the interval of the base frequency between
> incoming triggers and it needs to take system cycles to do that. 
> That's what you're experiencing and these are the pitfalls of a
> mutliply by 2 and 3 function when dealing with realtime events.
> 
> The interval is the same as what it's receiving, it just lags behind a
> few steps.  This is why the input is called 'Phase lock' and not
> 'external clock'
> 
> My suggestion:  use the M28 as the master clock.  Run the Oberkorn
> from it.
> 
> Phil and I are looking into an expander for the m28 - a simple analog
> clock to midi clock converter so that external midi devices can be
> synced easily to the goings-on of the M28.
> 
> 
> 
> 
> --- In PLAN_B_analog_blog@yahoogroups.com, "michaeltritter"
> <mtritter@> wrote:
> >
> > 
> > having trouble syncing the tap clock to external sources (e.g.
> analogue solutions oberkorn 
> > sequencer) via the phase lock... it always seems to go slowly in and
> out of sync. quite a nice 
> > effect actually, but not necessarily the desired one.
> > 
> > anyone...?
> >
>