Danjel van Tijn

I am trying to generate 16th note pulses from my host for my pluggo plugin.

I was trying to use plugsync~ which gives bar/beat and then ticks (which are a value between 0. and 1.0 and represent a fraction of a beat)

There was a formula in the reference manual for deriving tempo from this: samplerate/ticks*60) but this was not working for me= (getting weird tempo values) which I thought I could just map to a tempo objects tempo in.

If the outputs were something like 96ppq, I would know what to do. I guess I am just confused!

I think I am just overlooking or misunderstanding the way this should be done with plugsync~

Also I noticed some past discussion about using plugphasor~ instead? (my host is Ableton Live 6)

All I want to do is generate 1/16th note triggers based on my host tempo.

If the outputs were something like 96ppq, I would know what to do. I guess I am just confused!
I think I am just overlooking or misunderstanding the way this should be done with plugsync~

All I want to do is generate 1/16th note triggers based on my host tempo.


confused-wth-plugsync

This works for me as far as getting tempo info from plugsync~

I'll post an example of using plugphasor to generate 16th note bangs here in a second.

Here is an example with plugphasor~. I didnt actually test it, in with pluggo, but I do similar things with rewire all the time, so it should work.

I will check this out tonight (so close to being finished this should help get the icing on the cake)

In the comments about setting the ratio for quarter notes as being 0.25 wouldn't the ratio for eight notes be 0.125 not 0.5?

In the comments about setting the ratio for quarter notes as being 0.25  wouldn't the ratio for eight notes be 0.125 not 0.5?

(wow I gotta slow down on the impulsive repsonses!)

hey man, use hostsync~ to learn how plugsync~ works. They are almost identical. you can use hostsync~ within max and play with the outlets to your hearts content. I think hostsync~ has one outlet which plugsync~ does not. Other than that, every outlet is identical.

hey man, use hostsync~ to learn how plugsync~ works. They are almost identical.  you can use hostsync~ within max and play with the outlets to your hearts content. I think hostsync~ has one outlet which plugsync~ does not. Other than that, every outlet is identical.


Yeah, the ratio is the number of 16s to the beat, not the measure. So with four 16s to a quarter note, the ratio is .25. Two 16s to an eight note is a ratio of .5. I know you said you got it, but maybe someone is reading this who doesn't.

Yeah, the ratio is the number of 16s to the beat, not the measure. So with four 16s to a quarter note, the ratio is .25. Two 16s to an  eight note is a ratio of .5.  I know you said you got it, but maybe someone is reading this who doesn't. 

SO now my step sequencer is all working in sync now. It locks to tempo and generates pulses every 16th note.

However, whenever I start my sequencer by pressing play in the host, I do not hear the first midi note. Everything else plays (and is in time) just not the very first step when the sequence first starts.

This is not the case when I am running the patch just within max.

Has anyone encountered this issue before? Is it something to do with pluggin buffers?

SO now my step sequencer is all working in sync now. It locks to tempo and generates pulses every 16th note.
However, whenever I start my sequencer by pressing play in the host, I do not hear the first midi note. Everything else plays (and is in time) just not the very first step when the sequence first starts.

thats common with startup. Its very hard to fix... same things happens when you have like fruity loops loaded as a vst. it misses the first beat =(

Wow that is too bad :( I made a notron style sequencer with cumulative transpose and stuff. If you miss the first note it can mess up the recording of the sequence. Maybe I can create a 1 bar delay option in the sequence and then shift the rest of my arrangement by a bar (e.g. 1 bar empty lead in).

> Wow that is too bad :( I made a notron style sequencer with cumulative transpose and stuff. If you miss the first note it can mess up the recording of the sequence. Maybe I can create a 1 bar delay option in the sequence and then shift the rest of my arrangement by a bar (e.g. 1 bar empty lead in).

it'd be great to see this patch when it's ready for prime-time. It 

sounds cool, I love hardware sequencers, especially freaky ones like the 

Danjel van Tijn wrote:
> Wow that is too bad :( I made a notron style sequencer with cumulative transpose and stuff. If you miss the first note it can mess up the recording of the sequence. Maybe I can create a 1 bar delay option in the sequence and then shift the rest of my arrangement by a bar (e.g. 1 bar empty lead in).
>
> Still sucks to have to do this :p
>
>
it'd be great to see this patch when it's ready for prime-time.  It 
sounds cool, I love hardware sequencers, especially freaky ones like the 
notron!

-- 
Cheers,
-Andrew
andrew_burgess@mac.com


You need to use the leftmost outlet of plugsync~ (the one that shows 

transport state) to "force" the first beat (at least that's how I do 

If you post your current bit of code that generates the steps, I 

At 9:53 PM -0600 4/23/07, Danjel van Tijn wrote:

>SO now my step sequencer is all working in sync now. It locks to 

>tempo and generates pulses every 16th note.

>However, whenever I start my sequencer by pressing play in the host, 

>I do not hear the first midi note. Everything else plays (and is in 

>time) just not the very first step when the sequence first starts.

>This is not the case when I am running the patch just within max.

>Has anyone encountered this issue before? Is it something to do with 

202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X / Major 

You need to use the leftmost outlet of plugsync~ (the one that shows 
transport state) to "force" the first beat (at least that's how I do 
it).

If you post your current bit of code that generates the steps, I 
could take a quick look....

At 9:53 PM -0600 4/23/07, Danjel van Tijn wrote:
>SO now my step sequencer is all working in sync now. It locks to 
>tempo and generates pulses every 16th note.
>However, whenever I start my sequencer by pressing play in the host, 
>I do not hear the first midi note. Everything else plays (and is in 
>time) just not the very first step when the sequence first starts.
>
>This is not the case when I am running the patch just within max.
>
>Has anyone encountered this issue before? Is it something to do with 
>pluggin buffers?

-- 
Dan Nigrin
Defective Records
202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X / Major 
Malfunction
http://www.defectiverecords.com
http://www.jackosx.com


> thats common with startup. Its very hard to fix... same things happens when you have like fruity loops loaded as a vst. it misses the first beat =( 

I can't really remember how I did it right now, but I worked around it 

by linking to the start message coming from plugsync~...oh wait, here's 

- please let me know how / if it works for you - it's been a while since 

jamez skrev:
> thats common with startup. Its very hard to fix... same things happens when you have like fruity loops loaded as a vst. it misses the first beat =(  
>
> LAME!  its not cyclings fault thou =0
I can't really remember how I did it right now, but I worked around it 
by linking to the start message coming from plugsync~...oh wait, here's 
the abstraction I did;
- please let me know how / if it works for you - it's been a while since 
I've used it.

I tried that last patch (thanks for posting!) but I actually got more problems: It did not start on beat (delayed by about an 1/8th) and I did not hear the first note.

Nick Inhofe posted an example of a patch using plugphasor~ in conjunction with plugsync~. The timing on this one has been working for me well. (starts the sequence on beat)

My plugin (will post shortly) locks to tempo nicely, and it even gets a trigger for the first step, you just don't hear a note play.

If there is a possibility that it is my patch, then I will put a bunch of debug stuff into it and trace it through at low tempo to see what happens. However, I have a feeling this may just be a vst issue (I remember having the same problem with reaktor plugins).

At 4:38 PM +0200 4/24/07, Andreas Wetterberg wrote:

>>thats common with startup. Its very hard to fix... same things 

>>happens when you have like fruity loops loaded as a vst. it misses 

>I can't really remember how I did it right now, but I worked around 

>it by linking to the start message coming from plugsync~...oh wait, 

>- please let me know how / if it works for you - it's been a while 

Andreas, the patch you posted will only work right if the transport 

is started exactly "on the beat" - if not, it will send a trigger, 

despite the transport being started "in between the beat"...

At 4:38 PM +0200 4/24/07, Andreas Wetterberg wrote:
>jamez skrev:
>>thats common with startup. Its very hard to fix... same things 
>>happens when you have like fruity loops loaded as a vst. it misses 
>>the first beat =( 
>>LAME!  its not cyclings fault thou =0
>I can't really remember how I did it right now, but I worked around 
>it by linking to the start message coming from plugsync~...oh wait, 
>here's the abstraction I did;
>- please let me know how / if it works for you - it's been a while 
>since I've used it.

Andreas, the patch you posted will only work right if the transport 
is started exactly "on the beat" - if not, it will send a trigger, 
despite the transport being started "in between the beat"...

Dan
-- 
Dan Nigrin
Defective Records
202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X / Major 
Malfunction
http://www.defectiverecords.com
http://www.jackosx.com


Here is my code for receiving the play/stop and sync info:

If the step sequencers receive a bang (1/16th of a beat trigger) then they output their step values.

I guess there may be some latency in processing and generatign the midi values but it should not be much.

Also I tried recording some of the midi sequence generated with quantising off. I noticed that the timining is actually not as tight as I thought. Each step could either be positively or negtively delayed by different amounts (maybe as much as 1/64th?)

anyways here it is (not much different from what Nick posted)

Here is my code for receiving the play/stop and sync info:
If the step sequencers receive a bang (1/16th of a beat trigger) then they output their step values.

> At 4:38 PM +0200 4/24/07, Andreas Wetterberg wrote:

>>> thats common with startup. Its very hard to fix... same things 

>>> happens when you have like fruity loops loaded as a vst. it misses 

>>> the first beat =( LAME! its not cyclings fault thou =0

>> I can't really remember how I did it right now, but I worked around 

>> it by linking to the start message coming from plugsync~...oh wait, 

>> - please let me know how / if it works for you - it's been a while 

> Andreas, the patch you posted will only work right if the transport is 

> started exactly "on the beat" - if not, it will send a trigger, 

> despite the transport being started "in between the beat"...

That is correct, Dan. And it's the intended behaviour, really. If you 

start it at a later point you will *always* get the 1st 16th, and then 

subsequent 16th notes are there, too, if I recall correctly. Oh, and I 

actually found this method to be really tight, when the results are 

Dan Nigrin skrev:
> At 4:38 PM +0200 4/24/07, Andreas Wetterberg wrote:
>> jamez skrev:
>>> thats common with startup. Its very hard to fix... same things 
>>> happens when you have like fruity loops loaded as a vst. it misses 
>>> the first beat =( LAME!  its not cyclings fault thou =0
>> I can't really remember how I did it right now, but I worked around 
>> it by linking to the start message coming from plugsync~...oh wait, 
>> here's the abstraction I did;
>> - please let me know how / if it works for you - it's been a while 
>> since I've used it.
>
> Andreas, the patch you posted will only work right if the transport is 
> started exactly "on the beat" - if not, it will send a trigger, 
> despite the transport being started "in between the beat"...
>
> Dan
That is correct, Dan. And it's the intended behaviour, really. If you 
start it at a later point you will *always* get the 1st 16th, and then 
subsequent 16th notes are there, too, if I recall correctly. Oh, and I 
actually found this method to be really tight, when the results are 
recorded q. off.

I think the trick is going to be to move everything down by a measure, and then use plugsync's bar count to reset the sequencer.

Alternatively, you could set the == box to 1, and then just have playback start at measure 0.

I think the trick is going to be to move everything down by a measure, and then use plugsync's bar count to reset the sequencer. 

Alternatively, you could set the == box to 1, and then just have playback start at measure 0.


>That is correct, Dan. And it's the intended behaviour, really. If 

>you start it at a later point you will *always* get the 1st 16th, 

>and then subsequent 16th notes are there, too, if I recall 

>correctly. Oh, and I actually found this method to be really tight, 

But if you send the first trigger "in between" the beat, aren't you 

sending that initial first trigger too soon?

>That is correct, Dan. And it's the intended behaviour, really. If 
>you start it at a later point you will *always* get the 1st 16th, 
>and then subsequent 16th notes are there, too, if I recall 
>correctly. Oh, and I actually found this method to be really tight, 
>when the results are recorded q. off.

But if you send the first trigger "in between" the beat, aren't you 
sending that initial first trigger too soon?

At 9:47 AM -0600 4/24/07, Danjel van Tijn wrote:

>Here is my code for receiving the play/stop and sync info:

>If the step sequencers receive a bang (1/16th of a beat trigger) 

>I guess there may be some latency in processing and generatign the 

>Also I tried recording some of the midi sequence generated with 

>quantising off. I noticed that the timining is actually not as tight 

>as I thought. Each step could either be positively or negtively 

>delayed by different amounts (maybe as much as 1/64th?)

Looking at your patch, I'd also suggest to change your ==~ -1 to an 

==~ 1 ; I think that might help with your dilemma.

FWIW, since you are just outputting bangs to drive the other parts of 

your patch, you could also do this stuff without going through 

audio-rate objects (rate~, change~, ==~), and just use the 

bar/beat/tick outlets from plugsync~, or even the raw ticks outlet 

(which is what I do, with a bit of math). See example below, which 

just shows you at the end the total # steps since the start of the 

sequence. You can then massage this number for your purposes.

You lose any advantage of audio rate scheduling at the point you 

convert to scheduler rate (when you trigger the bangs).

At 9:47 AM -0600 4/24/07, Danjel van Tijn wrote:
>Here is my code for receiving the play/stop and sync info:
>If the step sequencers receive a bang (1/16th of a beat trigger) 
>then they output their step values.
>
>I guess there may be some latency in processing and generatign the 
>midi values but it should not be much.
>
>Also I tried recording some of the midi sequence generated with 
>quantising off. I noticed that the timining is actually not as tight 
>as I thought. Each step could either be positively or negtively 
>delayed by different amounts (maybe as much as 1/64th?)

Looking at your patch, I'd also suggest to change your ==~ -1 to an 
==~ 1 ; I think that might help with your dilemma.

FWIW, since you are just outputting bangs to drive the other parts of 
your patch, you could also do this stuff without going through 
audio-rate objects (rate~, change~, ==~), and just use the 
bar/beat/tick outlets from plugsync~, or even the raw ticks outlet 
(which is what I do, with a bit of math).  See example below,  which 
just shows you at the end the total # steps since the start of the 
sequence.  You can then massage this number for your purposes.

You lose any advantage of audio rate scheduling at the point you 
convert to scheduler rate (when you trigger the bangs).

I'll take a look at your timing patch, what you are saying makes sense so this should work just as well.

>> That is correct, Dan. And it's the intended behaviour, really. If you 

>> start it at a later point you will *always* get the 1st 16th, and 

>> then subsequent 16th notes are there, too, if I recall correctly. Oh, 

>> and I actually found this method to be really tight, when the results 

> But if you send the first trigger "in between" the beat, aren't you 

> sending that initial first trigger too soon?

Thing is; I have never ever ever needed to stop playback to launch it 

mid-bar... ever... It must be a hypothetical issue only? I can't imagine 

a situation where you would want that kind of behaviour. My daw resets 

to the bar anyway. All I can tell you at this point is that its:

Dan Nigrin skrev:
>> That is correct, Dan. And it's the intended behaviour, really. If you 
>> start it at a later point you will *always* get the 1st 16th, and 
>> then subsequent 16th notes are there, too, if I recall correctly. Oh, 
>> and I actually found this method to be really tight, when the results 
>> are recorded q. off.
>
> But if you send the first trigger "in between" the beat, aren't you 
> sending that initial first trigger too soon?
>
> Dan
Thing is; I have never ever ever needed to stop playback to launch it 
mid-bar... ever... It must be a hypothetical issue only? I can't imagine 
a situation where you would want that kind of behaviour. My daw resets 
to the bar anyway. All I can tell you at this point is that its:
a) Simple, and
b) works for me, and
c)sharing is supposed to be fun!

>Thing is; I have never ever ever needed to stop playback to launch 

>it mid-bar... ever... It must be a hypothetical issue only?

Not really - if you stop/start Live for example, by Shift-SpaceBar, 

instead of just Space-Bar, it continues to play exactly where you 

left off, and doesn't reset to the beat. Many artists that use Live 

>I can't imagine a situation where you would want that kind of 

>behaviour. My daw resets to the bar anyway. All I can tell you at 

Never meant to imply that your patch didn't do exactly what you need 

it to! I just wanted to be sure that Danjel understood fully how it 

would behave, since he was having some troubles with his setup...

>Thing is; I have never ever ever needed to stop playback to launch 
>it mid-bar... ever... It must be a hypothetical issue only?

Not really - if you stop/start Live for example, by Shift-SpaceBar, 
instead of just Space-Bar, it continues to play exactly where you 
left off, and doesn't reset to the beat.  Many artists that use Live 
"live" use this functionality...

>I can't imagine a situation where you would want that kind of 
>behaviour. My daw resets to the bar anyway. All I can tell you at 
>this point is that its:
>a) Simple, and
>b) works for me, and
>c)sharing is supposed to be fun!

Never meant to imply that your patch didn't do exactly what you need 
it to!  I just wanted to be sure that Danjel understood fully how it 
would behave, since he was having some troubles with his setup...

Best,
Dan
-- 
Dan Nigrin
Defective Records
202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X / Major 
Malfunction
http://www.defectiverecords.com
http://www.jackosx.com


confused wth Plugsync~