Cycling 74 » Topic: mtr – unexpected duration on 'next' msg

mtr – unexpected duration on 'next' msg

leighhunt — Mon, 15 Jan 2007 10:11:30 +0000

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

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P comment 0 213 142 196617 Step through recorded data;
#P button 337 242 15 0;
#P newex 354 242 27 196617 int;
#P newex 354 285 30 196617 pack;
#N coll ;
#P newobj 354 308 53 196617 coll;
#P button 354 196 15 0;
#P newex 353 215 43 196617 clocker;
#P message 200 325 50 196617 1 -1;
#P newex 200 293 62 196617 prepend set;
#P number 264 366 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 141 213 30 196617 next;
#P message 165 243 33 196617 clear;
#P message 164 177 29 196617 play;
#P message 164 159 41 196617 rewind;
#P message 164 141 29 196617 stop;
#P message 164 123 40 196617 record;
#P newex 247 243 27 196617 mtr;
#P newex 246 209 64 196617 speedlim 30;
#P number 246 118 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P comment 164 103 292 196617 Press record to record some value changes from number box;
#P comment 59 325 142 196617 Track/Duration info on ‘next ‘;
#P connect 3 0 4 1;
#P connect 3 0 19 0;
#P connect 3 0 17 1;
#P connect 6 0 4 0;
#P connect 6 0 14 0;
#P connect 5 0 4 0;
#P connect 5 0 15 0;
#P connect 4 0 12 0;
#P connect 12 0 13 0;
#P connect 2 0 3 0;
#P connect 10 0 4 0;
#P connect 9 0 4 0;
#P connect 8 0 4 0;
#P connect 7 0 4 0;
#P connect 4 1 11 0;
#P connect 17 0 16 0;
#P connect 15 0 14 0;
#P connect 19 0 18 0;
#P connect 18 0 17 0;
#P connect 14 0 18 1;
#P window clipboard copycount 21;

Re: mtr – unexpected duration on 'next' msg

seejayjames — Tue, 16 Jan 2007 00:58:28 +0000

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

Re: mtr – unexpected duration on 'next' msg

leighhunt — Tue, 16 Jan 2007 20:16:23 +0000

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
—————————————————-

Re: mtr – unexpected duration on 'next' msg

Stefan Tiedje — Wed, 17 Jan 2007 15:32:31 +0000

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

Re: mtr – unexpected duration on 'next' msg

leighhunt — Thu, 18 Jan 2007 00:31:50 +0000

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
>
>
—————————————————-

Re: mtr – unexpected duration on 'next' msg

furiousgreencloud — Wed, 26 Aug 2009 03:42:06 +0000

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.

- fgc

Re: mtr – unexpected duration on 'next' msg

Ben Bracken — Wed, 26 Aug 2009 19:52:44 +0000

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

-Ben