Forums > MaxMSP

known bug?

November 24, 2007 | 11:54 pm

try this
for the waveform object

max v2;
#N vpatcher 40 97 1179 715;
#P window setfont "Sans Serif" 20.;
#P window linecount 5;
#P comment 717 269 176 196628 4 you got a strange selecton formed by the old and the new startpoint?;
#P window linecount 4;
#P comment 897 114 176 196628 3 sel a sample’s part close to the begin of the waveform;
#P comment 711 116 176 196628 2 sel a sample’s part close to the end of the waveform;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 408 76 48 196617 loadbang;
#P user waveform~ 449 293 261 74 3 9;
#W mode select;
#W mouseoutput continuous;
#W unit ms;
#W grid 1000.;
#W ticks 0;
#W labels 1;
#W vlabels 0;
#W vticks 1;
#W bpm 120. 4.;
#W frgb 33 0 0;
#W brgb 60 178 173;
#W rgb2 0 95 255;
#W rgb3 0 0 0;
#W rgb4 0 0 0;
#W rgb5 190 137 255;
#W rgb6 100 100 100;
#W rgb7 100 100 100;
#P message 408 103 45 196617 set ciao;
#P user waveform~ 444 132 261 77 3 9;
#W mode select;
#W mouseoutput up;
#W unit ms;
#W grid 1000.;
#W ticks 0;
#W labels 1;
#W vlabels 0;
#W vticks 1;
#W bpm 120. 4.;
#W frgb 33 0 0;
#W brgb 60 178 173;
#W rgb2 0 95 255;
#W rgb3 0 0 0;
#W rgb4 0 0 0;
#W rgb5 190 137 255;
#W rgb6 100 100 100;
#W rgb7 100 100 100;
#P window setfont "Sans Serif" 20.;
#P message 150 62 79 196628 replace;
#P newex 149 116 185 196628 buffer~ ciao 3000;
#P comment 92 26 176 196628 1 charge a sound;
#P connect 2 0 1 0;
#P connect 6 0 4 0;
#P connect 4 0 3 0;
#P connect 4 0 5 0;
#P connect 3 2 5 2;
#P connect 3 3 5 3;
#P pop;



grg
November 25, 2007 | 1:30 pm

Am 25.11.2007 um 00:54 schrieb lorbi:
> try this
> for the waveform object

I first thought it was this bug again
http://www.cycling74.com/forums/index.php?t=tree&th=15759&mid=52188
not the redraw one, the one 3 posts down the thread, but that has long
been fixed (thanks cy74 by the way).

I thinks whats happening is just strict right to left output from the
upper waveform~, so if the new endpoint is before the old startpoint,
it can’t be set, but the new startpoint that arrives a little later
will. For a more intelligent way to sync 2 waveform~s try the link out.

cheers, g.


November 25, 2007 | 5:07 pm

hi, that’s not a bug, it’s because 1) objects in max output right- to left and 2) waveform~ will not allow the start of a selection to be placed behind the end.

This should work:

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 540 245 27 196617 f;
#P newex 459 215 29 196617 t b f;
#P newex 323 74 48 196617 loadbang;
#P user waveform~ 354 266 261 74 3 9;
#W mode select;
#W mouseoutput continuous;
#W unit ms;
#W grid 1000.;
#W ticks 0;
#W labels 1;
#W vlabels 0;
#W vticks 1;
#W bpm 120. 4.;
#W frgb 33 0 0;
#W brgb 60 178 173;
#W rgb2 0 95 255;
#W rgb3 0 0 0;
#W rgb4 0 0 0;
#W rgb5 190 137 255;
#W rgb6 100 100 100;
#W rgb7 100 100 100;
#P message 323 101 45 196617 set ciao;
#P user waveform~ 359 130 261 77 3 9;
#W mode select;
#W mouseoutput up;
#W unit ms;
#W grid 1000.;
#W ticks 0;
#W labels 1;
#W vlabels 0;
#W vticks 1;
#W bpm 120. 4.;
#W frgb 33 0 0;
#W brgb 60 178 173;
#W rgb2 0 95 255;
#W rgb3 0 0 0;
#W rgb4 0 0 0;
#W rgb5 190 137 255;
#W rgb6 100 100 100;
#W rgb7 100 100 100;
#P connect 1 0 2 0;
#P connect 1 0 0 0;
#P connect 4 1 2 2;
#P connect 4 0 5 0;
#P connect 0 2 4 0;
#P connect 5 0 2 3;
#P connect 0 3 5 0;
#P connect 3 0 1 0;
#P window clipboard copycount 6;

Hth,
Mattijs


November 25, 2007 | 5:20 pm

ok.

so it’s not a bug.

it’s just a strange thing.

thank’s

L.


November 25, 2007 | 7:52 pm

>2) waveform~ will not allow the start of a selection to be placed behind the end.

That depends the order in which they arrive (see patcher below)

> so it’s not a bug.

hmmm

_
johan

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 610 332 33 196617 swap;
#P newex 468 136 48 196617 loadbang;
#P user waveform~ 486 379 261 74 3 9;
#W mode select;
#W mouseoutput continuous;
#W unit ms;
#W grid 1000.;
#W ticks 0;
#W labels 1;
#W vlabels 0;
#W vticks 1;
#W bpm 120. 4.;
#W frgb 33 0 0;
#W brgb 60 178 173;
#W rgb2 0 95 255;
#W rgb3 0 0 0;
#W rgb4 0 0 0;
#W rgb5 190 137 255;
#W rgb6 100 100 100;
#W rgb7 100 100 100;
#P message 467 161 45 196617 set ciao;
#P user waveform~ 486 205 261 77 3 9;
#W mode select;
#W mouseoutput up;
#W unit ms;
#W grid 1000.;
#W ticks 0;
#W labels 1;
#W vlabels 0;
#W vticks 1;
#W bpm 120. 4.;
#W frgb 33 0 0;
#W brgb 60 178 173;
#W rgb2 0 95 255;
#W rgb3 0 0 0;
#W rgb4 0 0 0;
#W rgb5 190 137 255;
#W rgb6 100 100 100;
#W rgb7 100 100 100;
#P newex 408 302 92 196617 buffer~ ciao 3000;
#P connect 2 0 1 0;
#P connect 2 0 3 0;
#P connect 5 0 3 3;
#P connect 5 1 3 2;
#P connect 1 3 5 1;
#P connect 1 2 5 0;
#P connect 4 0 2 0;
#P window clipboard copycount 6;


November 26, 2007 | 9:21 am

Mattijs Kneppers schrieb:
> hi, that’s not a bug, it’s because 1) objects in max output right- to
> left and 2) waveform~ will not allow the start of a selection to be
> placed behind the end.

That’s a perfect explanation. But it could be called a design bug. It
wouldn’t be hard to exchange that "will not allow the start of a
selection to be placed behind the end" rule into "sorts automatically"
and allow it, or looks for values which come in the same tick, and only
allow it for that case. There are other circumstances which bug me
always. To reset the selection to 0, always requires to send the
selection two times…

I vote for it being a bug!
A fix won’t break old patches, but would allow to simplify old patches…

Stefan


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


November 26, 2007 | 11:11 am

On 26 nov. 07, at 10:21, Stefan Tiedje wrote:

> That’s a perfect explanation. But it could be called a design bug.
> It wouldn’t be hard to exchange that "will not allow the start of a
> selection to be placed behind the end" rule into "sorts
> automatically" and allow it, or looks for values which come in the
> same tick, and only allow it for that case. There are other
> circumstances which bug me always. To reset the selection to 0,
> always requires to send the selection two times…
>
> I vote for it being a bug!
> A fix won’t break old patches, but would allow to simplify old
> patches…

I fixed that in a way that if you send a list to the third inlet it
won’t cause such kind of issue. Waiting the next tick solution might
break old patches.

ej


November 28, 2007 | 1:27 pm

This is not a bug, it is simply the way Max works (implicit serialization of messages, right-to-left order, etc.) combined with the fact that waveform~ insists on start time always preceding end time.

You have the same situation with updating min/max on scale and some other objects. (Aside: lp.scampi & Co. allow range inversion, so it’s not a problem with the Litter Power objects).

It may inconvenient, but it’s the way Max works. When you let go of a light bulb, it falls and breaks when it hits the floor. That’s inconvenient, too, but I wouldn’t call gravity a "bug". It’s the way the universe works.

The only solution is to give send waveform~ a list message, updating both start/end time in a single message. Emmanuel’s suggestion would be perfect. But it doesn’t work when I try it here (I get an error message in the Max window and the selection remains unchanged). Maybe I misunderstood something. Using Max/MSP 4.6.3.

[img]index.php?t=getfile&id=1003&private=0[/img]

– P.


November 28, 2007 | 9:54 pm

Quote: Peter Castine wrote on Wed, 28 November 2007 14:27
—————————————————-
> This is not a bug, it is simply the way Max works (implicit serialization of messages, right-to-left order, etc.) combined with the fact that waveform~ insists on start time always preceding end time.
>
> You have the same situation with updating min/max on scale and some other objects. (Aside: lp.scampi & Co. allow range inversion, so it’s not a problem with the Litter Power objects).
>
> It may inconvenient, but it’s the way Max works. When you let go of a light bulb, it falls and breaks when it hits the floor. That’s inconvenient, too, but I wouldn’t call gravity a "bug". It’s the way the universe works.

(Ha, great, another occasion to disagree with Peter :) Sorry, but this doesn’t make much sense. It is a matter of design, not just how max work. As you say, with your own objects you take into account that a situation might occur where high and low could arrive in reversed order. I think that is good design. If it is otherwise, mostly it is not the result of a well thought out strategy, but simply a matter of overlooking something. I say this based on experience making my own mistakes, not to point out flaws in others. "Wow, that’s stupid, I will fix that in the next version." I’ve said this many times. Actually it is not scale, but zmap which has this. It took me hours to find out why something didn’t work which intuitively and logically should work. When teaching I always warn to use zmap only when you’re never going to update it’s arguments, ever. Nou breekt mijn klomp. http://www.cycling74.com/forums/index.php?t=msg&rid=106&S=2eef7c19107d68cd521751d858f01996&th=7392&goto=22217#msg_22217

_
johan


Viewing 9 posts - 1 through 9 (of 9 total)