cebec

Using a metro-locked phasor does not seem to enable recording into seq~ like a 'regular' phasor. Also, the message 'eraseall' does not seem to work like 'clear'.

Also, a question: What's the best way to maintain the tightness of signal domain sequencing after the seq~ object?

max-5-problems-with-seq

Maybe I'm not understand you, but you have no transport in your patch. This means the metro isn't locked to anything. For example, I can get your locked phasor to work by simply going to the Max5 menubar under the "Extras" heading, selecting "GlobalTransport", and then activating the GlobalTransport. At that point, your locked phasor works find according to whatever BPM i've input into the Global transport.

In other words, phasors do not lock to metros, they lock to transports as do metros and all the other tempo-lockables.

Here's a mod to your patch to demonstrate more quickly than my words might:

Yes, I was using the Global Transport to test this patch. Are you able to get the seq~ to record bangs at all when using the Global Transport with the locked phasor?

Hi,
Yes, I was using the Global Transport to test this patch. Are you able to get the seq~ to record bangs at all when using the Global Transport with the locked phasor?

Ah, sorry, I misunderstood your problem, basically, you have attached to the inlet, which means the message coming out is actually "escape bang", so you need at the outlet of seq~ to filter out the "escape" in the message and get the appropriate bang message.

Ah, sorry, I misunderstood your problem, basically, you have  attached to the inlet, which means the message coming out is actually "escape bang", so you need  at the outlet of seq~ to filter out the "escape" in the message and get the appropriate bang message.

Hmm, it's still not working. If I switch to the regular phasor after having recorded using the locked phasor, it'll play the events back but not if I'm using the locked phasor to play back.

That's weird, it's working perfectly for me no matter which phasor~ i choose... try this one, this time, click on "tempo 60" to make sure your locked phasor is running at the same tempo as your regular one. And, just to make sure you're not recording over previous runs with silence/inaction, do me a favor and click on record, overdub, and play and leave them all on at the same time, while you record bangs into it.

I've also included a scope~ which should read a ramp from 0 to 1 no matter which phasor~ you choose. Let me know your results:

That's weird, it's working perfectly for me no matter which phasor~ i choose... try this one, this time, click on "tempo 60" to make sure your locked phasor is running at the same tempo as your regular one. And, just to make sure you're not recording over previous runs with silence/inaction, do me a favor and click on record, overdub, and play and leave them all on at the same time, while you record bangs into it.
I've also included a scope~ which should read a ramp from 0 to 1 no matter which phasor~ you choose. Let me know your results:

Yeah - I'm seeing the same thing. We'll investigate - thanks for the patch.

Strange! Still nothing... Definitely outputting a ramp but the seq~ is not playing back the bangs...

Quote: RabidRaja wrote on Wed, 20 August 2008 11:26

----------------------------------------------------

> That's weird, it's working perfectly for me no matter which phasor~ i choose... try this one, this time, click on "tempo 60" to make sure your locked phasor is running at the same tempo as your regular one. And, just to make sure you're not recording over previous runs with silence/inaction, do me a favor and click on record, overdub, and play and leave them all on at the same time, while you record bangs into it.

> I've also included a scope~ which should read a ramp from 0 to 1 no matter which phasor~ you choose. Let me know your results:

Strange! Still nothing... Definitely outputting a ramp but the seq~ is not playing back the bangs... 

Quote: RabidRaja wrote on Wed, 20 August 2008 11:26
----------------------------------------------------
> That's weird, it's working perfectly for me no matter which phasor~ i choose... try this one, this time, click on "tempo 60" to make sure your locked phasor is running at the same tempo as your regular one. And, just to make sure you're not recording over previous runs with silence/inaction, do me a favor and click on record, overdub, and play and leave them all on at the same time, while you record bangs into it.
> I've also included a scope~ which should read a ramp from 0 to 1 no matter which phasor~ you choose. Let me know your results:
>
>
>
>
----------------------------------------------------


sorry to hear this is happening for you, it's been working for me. it sounds like Andrew Pask is having the same result and that he or other devs are looking into it so i'll just let them take care of it for now. Keep me updated, though if you get any further locating the problem or any workarounds/solutions.

(it's really strange if it outputs the same ramp that seq~ wouldn't respond appropriately... i'll keep looking at it, too...)

oh, wait, you're on windows, crap, i didn't see that until now. sorry, so it might be a windows independent problem. I'm on MacOSX. in that case, i'd let Andrew and the team investigate. you could also send an email directly to

let them know the problem and the exact specs of your computer and then reference this thread so that they can look into the details and corroborate with Andrew and the team further.

oh, wait, you're on windows, crap, i didn't see that until now. sorry, so it might be a windows independent problem. I'm on MacOSX. in that case, i'd let Andrew and the team investigate. you could also send an email directly to
support at cycling 74 dot com
let them know the problem and the exact specs of your computer and then reference this thread so that they can look into the details and corroborate with Andrew and the team further.


Thanks for your help. I'll see if I encounter the problem on my OS X machine tonight.

oh and one more thing, even on my MacOSX machine, i still find the same problem with the "eraseall" message.

Just to clarify, if someone from Cycling '74 responds to a bug report saying, "Thanks for the report. We'll look into it," this means the bug has been logged in our bug-tracking system and sent on to the developers, and you don't need to do anything else unless someone contacts you for further info. Sending an email about this issue to support will just mean more redundant work for someone else.

Just to clarify, if someone from Cycling '74 responds to a bug report saying, "Thanks for the report. We'll look into it," this means the bug has been logged in our bug-tracking system and sent on to the developers, and you don't need to do anything else unless someone contacts you for further info.  Sending an email about this issue to support will just mean more redundant work for someone else.

in taking a closer look at this, if you turn on 'scheduler in overdrive' and 'in audio interrupt' in your dsp settings, this patch works as expected.

I can see if this is just the way it is or if this is a bug, but regardless, I highly recommend that you have both of these options activated whenever you are doing anything with ITM.

Another thing, 'eraseall' is not a valid message to seq~, not sure where that came from. You want 'erase', which is the same as 'clear'.

in taking a closer look at this, if you turn on 'scheduler in overdrive' and 'in audio interrupt' in your dsp settings, this patch works as expected.  

Another thing, 'eraseall' is not a valid message to seq~, not sure where that came from.  You want 'erase', which is the same as 'clear'.

Quote: ben@cycling74.com wrote on Wed, 20 August 2008 15:55

> in taking a closer look at this, if you turn on 'scheduler in overdrive' and 'in audio interrupt' in your dsp settings, this patch works as expected. 

> I can see if this is just the way it is or if this is a bug, but regardless, I highly recommend that you have both of these options activated whenever you are doing anything with ITM.

> Another thing, 'eraseall' is not a valid message to seq~, not sure where that came from. You want 'erase', which is the same as 'clear'.

Sorry, it's in the seq~ help subpatch [editing] and it's 'erase all' not 'eraseall', you're right.

Also, 'add' and 'delete' entries in the seq~ Reference are transposed.

By the way, excuse my ignorance, but what is ITM? This is the second time in as many days that I've seen the acronym.

Quote: ben@cycling74.com wrote on Wed, 20 August 2008 15:55
----------------------------------------------------
> in taking a closer look at this, if you turn on 'scheduler in overdrive' and 'in audio interrupt' in your dsp settings, this patch works as expected.  
>
> I can see if this is just the way it is or if this is a bug, but regardless, I highly recommend that you have both of these options activated whenever you are doing anything with ITM.
>
> Another thing, 'eraseall' is not a valid message to seq~, not sure where that came from.  You want 'erase', which is the same as 'clear'.
>
> All the best,
> -Ben
>
>
----------------------------------------------------

Sorry, it's in the seq~ help subpatch [editing] and it's 'erase all' not 'eraseall', you're right.
Also, 'add' and 'delete' entries in the seq~ Reference are transposed.
By the way, excuse my ignorance, but what is ITM? This is the second time in as many days that I've seen the acronym.

oh, and my mistake for saying to contact support further, i'll remember to watch out for the devs from now on.

the seq~ documentation error has been fixed for the next incremental.

using 'scheduler in audio interrupt' fixed it instantly.

hey guys,
i was suffering this same problem.
using 'scheduler in audio interrupt' fixed it instantly.
should this be necessary though?
t


On 7 sept. 08, at 13:44, trent.gill wrote:

> using 'scheduler in audio interrupt' fixed it instantly.

For any precise timing scheduler in audio interrupt is required.

> hey guys,
> i was suffering this same problem.
> using 'scheduler in audio interrupt' fixed it instantly.
> should this be necessary though?

Max 5: problems with seq~