lorbi

known-bug

https://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 

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.

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

I first thought it was this bug again
https://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.

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.

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

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

> 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

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 

A fix won't break old patches, but would allow to simplify old patches...

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 Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com

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

> A fix won't break old patches, but would allow to simplify old 

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 

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

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]

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. 

https://cycling74.com/forums/index.php?t=msg&rid=106&S=2eef7c19107d68cd521751d858f01996&th=7392&goto=22217#msg_22217

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. https://cycling74.com/forums/index.php?t=msg&rid=106&S=2eef7c19107d68cd521751d858f01996&th=7392&goto=22217#msg_22217

known bug?