Analogue-sequencer

Hi,

I don't know what it is, but software Midi Clock support seems to get worse
with every update (Cubase, Tracktion).  I still remember my old Atari Falcon
with Cubase on it - the midi clock output was just tight; no glitches
nothing. But today :-(.

I asked around (Steinberg, Tracktion user forum) and they all seem to be
pretty sure that Midi Clock is inferior to Midi Timecode. Thus my question:
Would it be possible for the P3 to support Midi Timecode (only for
synchronization not absolute positioning)?

Sascha


[Non-text portions of this message have been removed]

> I asked around (Steinberg, Tracktion user forum) and they all 
> seem to be
> pretty sure that Midi Clock is inferior to Midi Timecode. 
> Thus my question:
> Would it be possible for the P3 to support Midi Timecode (only for
> synchronization not absolute positioning)?

MIDI clock and MIDI timecode are very different.
MIDI clock is tempo related.
MIDI timecode is just a linear representation of absolute time - like SMPTE.
The reason modern sequencers are better with MTC than MIDI clock is because
they are primarily working with WAV files, which always want to play back at
the same rate.
So they'd rather synchronise to an absolute time reference than a tempo
clock which might vary.

Timebase conversion from linear time to a preset tempo clock would be a
fairly complex bit of coding, and not something there is scope for in the
remaining space in P3 I'm afraid.

Best regards,
Colin Fraser
Sequentix Music Systems Ltd
http://www.sequentix.com

sascha.matzke@... wrote:
> 
> I asked around (Steinberg, Tracktion user forum) and they all seem to be
> pretty sure that Midi Clock is inferior to Midi Timecode. 

That's interesting to hear that midi time code is "inferior" to MTC -
they are two completely different things - midi clock is a time
reference, while MTC are simply addresses.

When Timecode is used, there is another time reference - in video and
digital, it is the master sync generator.  (That's why Steinberg and
Traction like MTC - they have a sync input).

Without a master sync source,  two devices trying to be run in sync
will start together from a given timecode address, but will try to run
separately on the internal clocks of each device and eventually drift
apart.

Try locking up two digital devices with "timecode only" sync, and they
will drift after a minute - and will be really far gone in five
minutes.  You will see that even computers need a single external time
reference.  There is usually a "resync" feature - which allows one
machine periodically to correct it's error.  This is like periodically
turning the wheel to correct a car constantly drifting off line - it
doesn't help the groove, if you know what I mean....

So, when syncronizing devices that don't have a sync clock input, midi
clock is the only click-accurate way to go.

Timecode only sync works only when Tequilla is in the patch...8*)

gary

> That's interesting to hear that midi time code is "inferior" to MTC -
> they are two completely different things - midi clock is a time
> reference, while MTC are simply addresses.

I'm not sure what you mean by "simply addresses". MIDI Time Code  
(MTC) is a MIDI encoding of timecode (hours/minutes/secs/frames),  
whereas MIDI Beat Clock is an encoding of bar, beat and beat  
division. (MIDI beat clocks run at 24 per quarter-note; the SPP  
locator messages are more coarse, to the nearest four or six clocks  
(I don't remember which).)

If you want to lock rhythmic instruments using MTC, then they'll have  
to have the same tempo map, and be reasonably accurate following it.

> Try locking up two digital devices with "timecode only" sync, and they
> will drift after a minute - and will be really far gone in five
> minutes.

When I was gigging for mindSpiral, we had several devices running at  
the same tempo (including my trusty P3), but had problems getting  
some of the plug-in systems to lock to beat clock, so for the most  
part we let them free-run, with no discernable drift. I would expect  
devices doing MTC-to-beat conversion themselves to be no worse than  
this.

	-- N.


   nick rothwell -- composition, systems, performance -- http:// 
www.cassiel.com

Nick,

I am not disputing that you and others have had success using MTC - I
use it all the time.  But I am just pointing out the difference
between the two.  

MTC offers nothing but a precision starter, at a certain address,
starting the machines all at once, hoping that the internal clocks
will run together long enough not to cause a problem.

Some applications, for example ACID, cannot sync to midi clock - only
be triggered by MTC.  Unfortunately, it also cannot output the exact
same tempo that my some of my other sequencer do.  For that matter, I
have the same issue with the P3 (not being able to get EXACTLY the
same tempo as the master sequencer).  

But I can send midi clock to the P3 and it will play in sync, because
midi clock is a tempo reference.  The matter with ACID remains
unsolved, because MTC is not a timing reference - it is a list of
addresses from which to start or locate.... 8*)

gc



Nick Rothwell <nick@...> wrote:

>
> > That's interesting to hear that midi time code is "inferior" to MTC -
> > they are two completely different things - midi clock is a time
> > reference, while MTC are simply addresses.
> 
> I'm not sure what you mean by "simply addresses". MIDI Time Code  
> (MTC) is a MIDI encoding of timecode (hours/minutes/secs/frames),  
> whereas MIDI Beat Clock is an encoding of bar, beat and beat  
> division. (MIDI beat clocks run at 24 per quarter-note; the SPP  
> locator messages are more coarse, to the nearest four or six clocks  
> (I don't remember which).)
> 
> If you want to lock rhythmic instruments using MTC, then they'll have  
> to have the same tempo map, and be reasonably accurate following it.
> 
> > Try locking up two digital devices with "timecode only" sync, and they
> > will drift after a minute - and will be really far gone in five
> > minutes.
> 
> When I was gigging for mindSpiral, we had several devices running at  
> the same tempo (including my trusty P3), but had problems getting  
> some of the plug-in systems to lock to beat clock, so for the most  
> part we let them free-run, with no discernable drift. I would expect  
> devices doing MTC-to-beat conversion themselves to be no worse than  
> this.
> 
> 	-- N.
> 
> 
>    nick rothwell -- composition, systems, performance -- http:// 
> www.cassiel.com
>

You guys are confusing timestamping with an actual time reference.

OK, so MTC is sending an arbitrary clock to reference the two machines
- it is not sending the EXACT interval of the tempo - you are
assumming that each and every one of your devices are individually
calcualting the tempo IDENTICALLY.

All that I am saying is that, when running with MTC, if the individual
machines do not output the exact tempo as the next, and they do not
run together, you are SOL, even if you believe that MTC provides
'absolute lock".  (Which I don't).

The Wilkopedia articles discuss how often MTC outputs data to provide
"sync".  Once again, this is the generator's speed to announce where
it is - how quickly it sends data to the display.

This isn't the issue - it is how often the slave checks the master
code.  Most all of MTC devices list parameters about how often the
device should look at the master MTC, and how slop there should be in
the case of error. 

gary


Nick Rothwell <nick@...> wrote:
>
Assuming maths of  

> sufficient accuracy, two devices with the same tempo figure should be  
> able to stay locked by constantly doing the frames-to-beats  
> calculations; they aren't free-running.

Hi,

On 5/31/06, Gary Chang <gchang@calarts.edu> wrote:
>
> MTC offers nothing but a precision starter, at a certain address,
> starting the machines all at once, hoping that the internal clocks
> will run together long enough not to cause a problem.


That's not true. MTC provides an absolute time reference - continuously.

See http://en.wikipedia.org/wiki/MIDI_timecode and
http://www.borg.com/~jglatt/tech/mtc.htm for more information.

Sascha


[Non-text portions of this message have been removed]

Saacha,

I don't disagree with your observation - if, in fact, you have a
device that will calculate tempos referencing an absolute time
reference, then that is ideal - I have that - in my Protools system,
referencing a house sync generator that phase locks everything,
including MTC.  

The problem in my studio is that ACID (or, more specifically, Windows
XP and its drivers) is not as accurate a calculator to convert the MTC
to same tempo as Protools - it is not as stable, even when locked to
this pristine absolute timing source.

So, all I am saying is that assuming that two devices are able to play
at identical tempos is assuming quite a lot.

gary

sascha.matzke@... wrote:
>
> Hi,
> 
> On 5/31/06, Colin f <colin@...> wrote:
> >
> > If you can assume that absolute to relative timebase conversion is
going
> > to
> > be accurate, you would expect the handling of MIDI clock would be
equally
> > accurate too, in which case, you wouldn't be considering using MTC
to get
> > round dodgy MIDI clock handling.
> 
> 
> Not quite - in my understanding - with midi clock you have to depend
on a
> as-close-to-realtime-as-possible behaviour of the midi clock master.
Most
> software sequencers these days produce considerable jitter on their midi
> clock output which is definitely a problem (for instance when I
scroll or
> zoom in Tracktion the midi clock gets noticeable slower and recovers
when I
> stop).
> 
> IMO with MTC this problem could at least be partially solved as MTC
messages
> contain absolute time references which could be used to calculate the
> current tempo independent from interval in which those message are
arriving.
> So yes, the MTC slave would run on it's own tempo, but (dependend on the
> processing power available) would be able to provide better
synchronization

> with devices which are not capable of "realtime" sync output (which
> conceptually would be any software on a "modern" preemptive multitasking
> operation system uncapable of providing realtime scheduling).
> 
> Sascha
> 
> 
> [Non-text portions of this message have been removed]
>

On 31 May 2006, at 09:27, sascha.matzke@gmail.com wrote:

> That's not true. MTC provides an absolute time reference -  
> continuously.

Indeed - that's the whole point of timecode. Assuming maths of  
sufficient accuracy, two devices with the same tempo figure should be  
able to stay locked by constantly doing the frames-to-beats  
calculations; they aren't free-running. My original point was that  
devices seem to do a pretty good job even if they *are* free-running,  
so timecode-lock should be no worse.

	-- N.


   nick rothwell -- composition, systems, performance -- http:// 
www.cassiel.com

One thing I tried when I had problems using the P3 with Tracktion 
[software sequencer/VST host], was to use midiox's internal clock generator.

I used midiox as the clock master and it drove both Tracktion via MTC 
and the P3 via midiclock. midiox will generate MTC and midiclock 
simultaneously. Your only problem will be that you don't have tempo 
automation. Its also PC only.

I should add that it didn't work very well with Tracktion because 
Tracktion's midi protocol was/is very buggy. It appears that midiclock 
was given a low priority because it wasn't as 'professional' as MTC...

Tony

www.oakleysound.com

> > That's not true. MTC provides an absolute time reference -  
> > continuously.
> 
> Indeed - that's the whole point of timecode. Assuming maths of  
> sufficient accuracy, two devices with the same tempo figure 
> should be  
> able to stay locked by constantly doing the frames-to-beats  
> calculations;

That's where the theory falls down...
If you can assume that absolute to relative timebase conversion is going to
be accurate, you would expect the handling of MIDI clock would be equally
accurate too, in which case, you wouldn't be considering using MTC to get
round dodgy MIDI clock handling.

Best regards,
Colin Fraser
Sequentix Music Systems Ltd
http://www.sequentix.com

>>Timebase conversion from linear time to a preset tempo clock would be a
>>fairly complex bit of coding, and not something there is scope for in the
>>remaining space in P3 I'm afraid.

Colin,

I think ive mentioned it before, but i cant find the conclusion -

I know that the concept of song position is not so relevant to the P3
itself, but there are multitrack instances where it is nice to 'jam' to a
pre-recorded loop.

At present, so far as im aware, there is no way to do this without slaving
the P3 - cubase / nuendo etc dont sync to clock, acid 'pretends' it does,
but not in a useful way, possibly logic does, but im not sure...

Would it be possible to allow the user to set totally arbitrary loop start
and end points that the P3 then outputs the MTC for?

eg. i go to the relevant page in the P3 menus, set my start point in bars
and beats, and the same with my end point.

now every time i hit 'run' on the P3 the internal MTC counter is reset to
the user configured start point whereby it then starts counting until it
reaches the 'end' point, and then loops back to outputing the MTC start
frame, etc.etc..

this looping is *not* the P3s play mode, and dosnt affect the P3s playing in
any way at all.  its *purely* extra data being sent out of the OUT port, in
order to allow the external sequencers to sync properly.

the concept, to me at least, seems pretty simple, and user friendly, but
obviously i know, well, zero about the amount of code needed for something
like that?

Julian

Hi,

On 5/31/06, Colin f <colin@colinfraser.com> wrote:
>
> If you can assume that absolute to relative timebase conversion is going
> to
> be accurate, you would expect the handling of MIDI clock would be equally
> accurate too, in which case, you wouldn't be considering using MTC to get
> round dodgy MIDI clock handling.


Not quite - in my understanding - with midi clock you have to depend on a
as-close-to-realtime-as-possible behaviour of the midi clock master. Most
software sequencers these days produce considerable jitter on their midi
clock output which is definitely a problem (for instance when I scroll or
zoom in Tracktion the midi clock gets noticeable slower and recovers when I
stop).

IMO with MTC this problem could at least be partially solved as MTC messages
contain absolute time references which could be used to calculate the
current tempo independent from interval in which those message are arriving.
So yes, the MTC slave would run on it's own tempo, but (dependend on the
processing power available) would be able to provide better synchronization
with devices which are not capable of "realtime" sync output (which
conceptually would be any software on a "modern" preemptive multitasking
operation system uncapable of providing realtime scheduling).

Sascha


[Non-text portions of this message have been removed]

On 31 May 2006, at 10:22, Colin f wrote:

> That's where the theory falls down...

Ah, you mean where it becomes practice? (Where the rubber hits the  
road, as our US cousins might say.)

> If you can assume that absolute to relative timebase conversion is  
> going to
> be accurate, you would expect the handling of MIDI clock would be  
> equally
> accurate too, in which case, you wouldn't be considering using MTC  
> to get
> round dodgy MIDI clock handling.

Agreed; if the timing code is dodgy, then relying on a different kind  
of timing code to solve the problem isn't going to help...

	-- N.


   nick rothwell -- composition, systems, performance -- http:// 
www.cassiel.com

On 31 May 2006, at 10:58, sascha.matzke@gmail.com wrote:

> for instance when I scroll or
> zoom in Tracktion the midi clock gets noticeable slower and  
> recovers when I
> stop

I think we can file that one under "shite coding".

	-- N.


   nick rothwell -- composition, systems, performance -- http:// 
www.cassiel.com