davidestevens

I have a [seq] in my patch into which I'm loading midi files containing chord sequences (1 chord per quarter note; 120bpm), which I want to play back at the master tempo set in my patch. And I'm having a hard time translating the "tick" help into something that works. How does 24 ticks/quarter note at 120bpm translate into the correct arguments for [metro]? Maybe obvious, but I'm failing to get my head around it.

So at the moment I have a [metro 128n] banging [tick] to the seq. I don't think this is right - the sequence (1 chord change every bar (4 beats) is changing every _6_ beats. And I don't understand what I'm trying to do well enough that I can make sense of it!

I have a [seq] in my patch into which I'm loading midi files containing chord sequences (1 chord per quarter note; 120bpm), which I want to play back at the master tempo set in my patch. And I'm having a hard time translating the "tick" help into something that works. How does 24 ticks/quarter note at 120bpm translate into the correct arguments for [metro]? Maybe obvious, but I'm failing to get my head around it.
So at the moment I have a [metro 128n] banging [tick] to the seq. I don't think this is right - the sequence (1 chord change every bar (4 beats) is changing every _6_ beats. And I don't understand what I'm trying to do well enough that I can make sense of it!
Any help gratefully received!

I have a [seq] in my patch into which I'm loading midi files containing chord sequences (1 chord per quarter note; 120bpm), which I want to 

locking-seq-to-master-tempo

I don't use [seq] but maybe here [translate] and [transport] are your friend.

Thanks - [translate] gives me a note value of 64n for metro (which is already locked to transport). (24 ticks -> 64n). But that is giving me a chord change (which in the midi file is every bar) on every 6 beats. That’s the bit I can’t get my head around! Thanks for the suggestions though. 

Thanks - [translate] gives me a note value of 64n for metro (which is already locked to transport). (24 ticks -> 64n).  But that is giving me a chord change (which in the midi file is every bar) on every 6 beats. That’s the bit I can’t get my head around! Thanks for the suggestions though. 


Tricky. I think the "tick" message to [seq] and the "ticks" notevalue type used by translate and metro etc. are not the same.

I don't use [seq], but the [seq] documentation for "tick" message says:

In order to play the sequence at its original recorded tempo, seq must receive 48 tick messages per second

This sounds like a tempo-independent rate (as it is explicity per-second) linked with the MIDI recorded. So maybe sending more than 48 "tick" messages per second will make the recording faster, and fewer than 48 will playback slower.

If I understand this correctly, you'd want 1000ms / 48 ---> [translate ms ticks] which would give you an interval for [metro] of 20 ticks if your current tempo is 120 bpm.

Thought of in a purely notevalues ticks world: a quarter note always has 480 ticks (regardless of tempo), and so 480 ticks / 24 = 20. And the 64n you used above would be 30 ticks. The 20:30 ratio would be the same as the 4-beat : 6-beat thing you're encountering.

Tricky.  I think the "tick" message to [seq] and the "ticks" notevalue type used by translate and metro etc. are not the same.  

This sounds like a tempo-independent rate (as it is explicity per-second) linked with the MIDI recorded.  So maybe sending more than 48 "tick" messages per second will make the recording faster, and fewer than 48 will playback slower.

If I understand this correctly, you'd want 1000ms / 48  ---> [translate ms ticks]  which would give you an interval for [metro] of 20 ticks if your current tempo is 120 bpm.  

Thought of in a purely notevalues ticks world: a quarter note always has 480 ticks (regardless of tempo), and so 480 ticks / 24 = 20.  And the 64n you used above would be 30 ticks.  The 20:30 ratio would be the same as the 4-beat : 6-beat thing you're encountering.

I am also facing issues with the games I play. 

tick message to seq is exactly same interval as midi clock.

if we are talking about ticks in terms of 

1/4 note = 480, midi clock is 24 x per 1/4note

96n in that case = does not exist as notevalue

metro 20 ticks should do, but i prefer old good metro in ms

I wonder how many times this was asked and answered on the forum

tick message to seq is exactly same interval as midi clock.


if we are talking about ticks in terms of 
1/4 note = 480, midi clock is 24 x per 1/4note
then 1 clock = 20 ticks
0r 1/96 of whole note

96n in that case = does not exist as notevalue
metro 20 ticks should do, but i prefer old good metro in ms

I wonder how many times this was asked and answered on the forum

Normally, neither do I, which is partly why I’m having trouble getting my head around it. 

48 ticks/sec makes each tick 20.833 ms long and (tries it out) I thought metro only accepted integer values, but it seems that floats work too. So I guess the next thing is to see if it’ll stay enough in sync with the master transport or the patch (my guess is no, but maybe I i can force a resync every 8 bars or so.). Or maybe figure out a way of achieving the same thing (tempo locked chord changes) using Colls, and use text files instead of midi files.

> I don't use [seq], 
Normally, neither do I, which is partly why I’m having trouble getting my head around it. 
48 ticks/sec makes each tick 20.833 ms long and (tries it out) I thought metro only accepted integer values, but it seems that floats work too. So I guess the next thing is to see if it’ll stay enough in sync with the master transport or the patch (my guess is no, but maybe I i can force a resync every 8 bars or so.). Or maybe figure out a way of achieving the same thing (tempo locked chord changes) using Colls, and use text files instead of midi files.

@sourceaudio thanks for the patch. I was getting closer, and had most of that except for the tempo to metro conversion bit. I'll try that and see if it stays in sync enough, but I'm beginning to think that for the particular thing I'm trying to do I'm going to ditch seq. I originally used midi files as I thought it would make it easier for users (ie primary teachers mostly) to create new sequences, but I'm now thinking that a text file loaded into Coll would be easier.

>I wonder how many times this was asked and answered on the forum

a fair few pages, but in the first couple (after which I lost interest) there wan't anything that useful for me.

if you want to use master transport, then simply use metro 20 ticks synced to it. 

or use transport object and use raw ticks to drive seq.

It would be even possible to reposition seq same as one would do using midi clock

Using ms based coll and chords in index lines, would also be my prefered approach.

What I refuse to use is that transport stuff.

You would have to drop it anyway for ms based coll

and use metro-counter combo for flexible tempo.

if tempo 120 = 1ms, you scale 120-240 1. 2.

if you want to use master transport, then simply use metro 20 ticks synced to it. 
or use transport object and use raw ticks  to drive seq.
It would be even possible to reposition seq same as one would do using midi clock
and song position pointer.
Using ms based coll and chords in index lines, would also be my prefered approach.
What I refuse to use is that transport stuff.
You would have to drop it anyway for ms based coll
and use metro-counter combo for flexible tempo.
and yes , metro can run sub ms intervals
if tempo 120 = 1ms, you scale 120-240 1. 2.
and 60 - 120 2. 1.  for tempos 60 - 240



here is a patch I use to import text based SEQ midi files into coll

locking seq to master tempo