leighhunt

II wonder if anyone could take a moment to have a look at this patch.I am trying to use the 'next' message to mtr in order for me to be able to change the speed of playback of data. 

On stepping through the events with the 'next message I am finding the occasional '2' for duration, when I would expect that the lowest to be '30'. Normally it occurs somewhere between the 20th & 35th next message

On the right side of the patch I have a coll setup to record the information too, using a clocker for coll index creation. When viewing the coll after recording I see no indices less than 30 apart, so speedlim is surely working properly.

Could someone possibly confirm this for me as I'n getting sore from scratching my head over this one?

I have tried the patch on PPC/Max4.62 and MacbookPro/Max4.62 with the same results;

Hi there,
II wonder if anyone could take a moment to have a look at this patch.I am trying to use the 'next' message to mtr in order for me to be able to change the speed of playback of data. 
On stepping through the events with the 'next message I am finding the occasional '2' for duration, when I would expect that the lowest to be '30'. Normally it occurs somewhere between the 20th & 35th next message
On the right side of the patch I have a coll setup to record the information too, using a clocker for coll index creation. When viewing the coll after recording I see no indices less than 30 apart, so speedlim is surely working properly.
Could someone possibly confirm this for me as I'n getting sore from scratching my head over this one?
I have tried the patch on PPC/Max4.62 and MacbookPro/Max4.62 with the same results;
Regards
Leigh Hunt

mtr-unexpected-duration-on-next-msg

Hey, that is strange. How does the mtr record durations that short after a speedlim?

Seq is more reliable / accurate, it seems, though I'm still unclear about what's going on with the mtr. I wonder if a range or split after the speedlim would further ensure 30-ms durations.

I tried reversing the pack as I thought it should be in this order (second int stored before banging the list out), but it turns out the original way was right I think.

I even checked a written mtr file (write, then open as text). No sign of the mysterious "2" durations in it OR in the coll. Weird!

I even checked a written mtr file (write, then open as text). No sign of the mysterious "2" durations in it OR in the coll.  Weird!

Firstly, thanks for taking the time to try the patch out....and

for the reassurance that my eyes were not deceiving me!

I hadn't tried saving then opening as text - same result for me, no mysterious '2's. Furthermore, when I reloaded the same file into mtr, the instances of '2's increased to one every 7!!

I'm now thinking of other ways to accomplish my aim as this isn't going to work for me. One possibility I thought of was to route a phasor~ driven counter through a coll. This begs another question from me regarding frugal use of resources;

If, for example, I wrote data to a coll as in the previously posted patch, then looped through the addresses, triggering existing addresses, would this be considered an 'expensive' way to achieve my aim, as this could amount to 1000 attempted address reads per second, per coll used, I would be looking at creating in the region of up to 128 of these colls.

(Processor overhead isn't of 'paramount' importance as I'm using MBP 2.33GHz, but I am running Logic Pro at the same time, with Soundflower16ch, Motu828 and 8Pre, 56 audio channels in all, at a latency setting of 128 samples).

I'm going to try the coll method for now anyway, I thought it might be worth mentioning here just in case someone could advise me of any possible pitfalls.

seejayjames wrote on Tue, 16 January 2007 00:58

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

> Hey, that is strange. How does the mtr record durations that short after a speedlim?

> Seq is more reliable / accurate, it seems, though I'm still unclear about what's going on with the mtr. I wonder if a range or split after the speedlim would further ensure 30-ms durations.

> I tried reversing the pack as I thought it should be in this order (second int stored before banging the list out), but it turns out the original way was right I think.

> I even checked a written mtr file (write, then open as text). No sign of the mysterious "2" durations in it OR in the coll. Weird!

Hi
Firstly, thanks for taking the time to try the patch out....and
for the reassurance that my eyes were not deceiving me!
I hadn't tried saving then opening as text - same result for me, no mysterious '2's. Furthermore, when I reloaded the same file into mtr, the instances of '2's increased to one every 7!!
I'm now thinking of other ways to accomplish my aim as this isn't going to work for me. One possibility I thought of was to route a phasor~ driven counter through a coll. This begs another question from me regarding frugal use of resources;
If, for example, I wrote data to a coll as in the previously posted patch, then looped through the addresses, triggering existing addresses, would this be considered an 'expensive' way to achieve my aim, as this could amount to 1000 attempted address reads per second, per coll used,  I would be looking at creating in the region of up to 128 of these colls.
(Processor overhead isn't of 'paramount' importance as I'm using  MBP 2.33GHz, but I am running Logic Pro at the same time, with Soundflower16ch, Motu828 and 8Pre, 56 audio channels in all, at a latency setting of 128 samples).
I'm going to try the coll method for now anyway, I thought it might be worth mentioning here just in case someone could advise me of any possible pitfalls.
regards
leigh

seejayjames wrote on Tue, 16 January 2007 00:58
----------------------------------------------------
> Hey, that is strange. How does the mtr record durations that short after a speedlim?
>
> Seq is more reliable / accurate, it seems, though I'm still unclear about what's going on with the mtr. I wonder if a range or split after the speedlim would further ensure 30-ms durations.
>
> I tried reversing the pack as I thought it should be in this order (second int stored before banging the list out), but it turns out the original way was right I think.
>
> I even checked a written mtr file (write, then open as text). No sign of the mysterious "2" durations in it OR in the coll.  Weird!
>
> --C
----------------------------------------------------


> I'm going to try the coll method for now anyway, I thought it might

> be worth mentioning here just in case someone could advise me of any

Have you considered seq~ as alternative to mtr?

Leigh Hunt wrote:
> I'm going to try the coll method for now anyway, I thought it might
> be worth mentioning here just in case someone could advise me of any
> possible pitfalls.

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


I just took a quick look at seq~, and indeed, it might well be perfect for what I wish to do. Thanks very much for pointing it out to me, I hadn't come across that object so far!

Quote: Stefan Tiedje wrote on Wed, 17 January 2007 15:32

> > I'm going to try the coll method for now anyway, I thought it might

> > be worth mentioning here just in case someone could advise me of any

> Have you considered seq~ as alternative to mtr?

Hi Stefan,
I just took a quick look at seq~, and indeed, it might well be perfect for what I wish to do. Thanks very much for pointing it out to me, I hadn't come across that object so far!
....so many objects....so little time...
regards
leigh
 Quote: Stefan Tiedje wrote on Wed, 17 January 2007 15:32
----------------------------------------------------
> Leigh Hunt wrote:
> > I'm going to try the coll method for now anyway, I thought it might
> > be worth mentioning here just in case someone could advise me of any
> > possible pitfalls.
>
> Have you considered seq~ as alternative to mtr?
>
> Stefan
>
> -- 
> Stefan Tiedje------------x-------
> --_____-----------|--------------
> --(_|_ ----|-----|-----()-------
> -- _|_)----|-----()--------------
> ----------()--------www.ccmix.com
>
>
----------------------------------------------------


I concur that this is a bug, here is a simple alternative "mtr" patch and help patch.

The main feature i needed was to know when the 'play' was complete.

The mtr duration issue should be fixed for the next incremental.

mtr - unexpected duration on 'next' msg