Mattijs

I had several occasions where this became a problem and has cost time:

I think this behaviour is not intuitive. I expect that I can depend on the output of the interface object to be within the user input range.

toggle-doesnt-act-intuitive

Yeah, it should be outputting just 1 or 0. Nice find...., but you're too late!! TOO LATE!! MUAHAHAHA!!

Yeah, it should be outputting just 1 or 0.  Nice find...., but you're too late!! TOO LATE!! MUAHAHAHA!!


>I think this behaviour is not intuitive. I expect that I can depend 

>on the output of the interface object to be within the user input 

it works as explained in the help patch....

>
>I think this behaviour is not intuitive. I expect that I can depend 
>on the output of the interface object to be within the user input 
>range.

kasper
-- 
  Kasper T. Toeplitz
noise, composition, bass, computer
http://www.sleazeArt.com

Quote: _jamez_ wrote on Tue, 06 February 2007 17:11

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

> Yeah, it should be outputting just 1 or 0. Nice find...., but you're too late!! TOO LATE!! MUAHAHAHA!!

(wait, maybe this secret switch toggles the auto destruct function. If only I could break the 512 bit code.. 10 seconds before impact.. I have to trust the feedback of this panel completely. If there is only one mistake we're all doomed)

Quote: _jamez_ wrote on Tue, 06 February 2007 17:11
----------------------------------------------------
> Yeah, it should be outputting just 1 or 0.  Nice find...., but you're too late!! TOO LATE!! MUAHAHAHA!!
----------------------------------------------------

Quote: Kasper T Toeplitz wrote on Tue, 06 February 2007 17:30

> >I think this behaviour is not intuitive. I expect that I can depend 

> >on the output of the interface object to be within the user input 

> it works as explained in the help patch....

Quote: Kasper T Toeplitz wrote on Tue, 06 February 2007 17:30
----------------------------------------------------
> >
> >I think this behaviour is not intuitive. I expect that I can depend 
> >on the output of the interface object to be within the user input 
> >range.
>
>
> it works as explained in the help patch....

>
> best
>
> kasper
> -- 
>   Kasper T. Toeplitz
> noise, composition, bass, computer
> http://www.sleazeArt.com
>
> http://www.myspace.com/sleazeart
>
>
----------------------------------------------------


This is all within the user input range - any non-zero number turns 

it on, zero turns it off - it passes the input on to the output.

Input    int    The number is sent out the outlet. If the number is not 0, 

toggle displays an X, showing it is on. If it is 0, toggle is blank, 

Output    int    A number received in the inlet is sent out the outlet. A 

bang or a mouse click sends 1 or 0 out the outlet, depending on 

whether toggle is being turned on or off.

On Feb 6, 2007, at 9:07 AM, Mattijs Kneppers wrote:

> I think this behaviour is not intuitive. I expect that I can depend 

> on the output of the interface object to be within the user input 

This is all within the user input range - any non-zero number turns  
it on, zero turns it off - it passes the input on to the output.

Input	int	The number is sent out the outlet. If the number is not 0,  
toggle displays an X, showing it is on. If it is 0, toggle is blank,  
showing it is off.

Output	int	A number received in the inlet is sent out the outlet. A  
bang or a mouse click sends 1 or 0 out the outlet, depending on  
whether toggle is being turned on or off.

>
> I think this behaviour is not intuitive. I expect that I can depend  
> on the output of the interface object to be within the user input  
> range.
>

On 6-Feb-2007, at 18:00, Mattijs Kneppers wrote:

The extent to which toggle's behavior is confusing is inversely 

proportional to how deeply your consciousness is imbued with C's 

IOW: this is great for those who think C/C++ is the best programming 

language ever to grace this planet. All a matter of taste (or lack 

Peter Castine +--> Litter Power & Litter Bundle for Jitter

Interface Building for |home | chez nous|

Max/MSP Extremely cool |bei uns | i nostri|

On 6-Feb-2007, at 18:00, Mattijs Kneppers wrote:
> I does, but it shouldn't!

The extent to which toggle's behavior is confusing is inversely  
proportional to how deeply your consciousness is imbued with C's  
bastard concept of "Boolean".

IOW: this is great for those who think C/C++ is the best programming  
language ever to grace this planet. All a matter of taste (or lack  
thereof).

--------------    http://www.bek.no/~pcastine/Litter/    -------------
Peter Castine             +--> Litter Power & Litter Bundle for Jitter
                                Universal Binaries on the way
iCE:  Sequencing,  Recording &
       Interface  Building  for                   |home    | chez nous|
       Max/MSP   Extremely cool                   |bei uns |  i nostri|
       http://www.dspaudio.com/                   http://www.castine.de

> I had several occasions where this became a problem and has cost

but only within the first half year of Max usage, then you know it by 

This can't be changed, as a lot of ancient patches rely on that 

behaviour. There are occasions where its helpfull, if you need to 

restrict it, pass it throug a [!= 0] object, if you always need the 

Mattijs Kneppers wrote:
> I had several occasions where this became a problem and has cost
> time:

but only within the first half year of Max usage, then you know it by 
heart...  ;-)

This can't be changed, as a lot of ancient patches rely on that 
behaviour. There are occasions where its helpfull, if you need to 
restrict it, pass it throug a [!= 0] object, if you always need the 
restriction, create a clipping...

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


On 6 Feb 2007, at 23:53, Stefan Tiedje wrote:

>> I had several occasions where this became a problem and has cost

> but only within the first half year of Max usage, then you know it 

You say that, but I read and worked through the manuals religiously 

about 8 years ago - and i had totally missed (or forgotten) the pass- 

through value bit. Which explains some problems I was having 

recently. Max is just so cool! So much stuff, so much depth.

> Mattijs Kneppers wrote:
>> I had several occasions where this became a problem and has cost
>> time:
>
> but only within the first half year of Max usage, then you know it  
> by heart...  ;-)

You say that, but I read and worked through the manuals religiously  
about 8 years ago - and i had totally missed (or forgotten) the pass- 
through value bit. Which explains some problems I was having  
recently. Max is just so cool! So much stuff, so much depth.
(ok - time to go to bed now)

Quote: smill wrote on Tue, 06 February 2007 18:57

> This is all within the user input range - any non-zero number turns 

> it on, zero turns it off - it passes the input on to the output.

I'm sorry, I meant user interface input range. It's an interface object, after all.

> Input    int    The number is sent out the outlet. If the number is not 0, 

> toggle displays an X, showing it is on. If it is 0, toggle is blank, 

> Output    int    A number received in the inlet is sent out the outlet. A 

> bang or a mouse click sends 1 or 0 out the outlet, depending on 

> whether toggle is being turned on or off.

Hey, I'm not saying that toggle is buggy. I'm only saying that a user interface element has the primary goal to reflect the state of the program on the screen as well as possible. And I think it could do that better than it currently does, by limiting its output to 0 and 1.

I don't think it can be changed, but well.. maybe it's nice input for future interface considerations.

> On Feb 6, 2007, at 9:07 AM, Mattijs Kneppers wrote:

> > I think this behaviour is not intuitive. I expect that I can depend 

> > on the output of the interface object to be within the user input 

Quote: smill wrote on Tue, 06 February 2007 18:57
----------------------------------------------------
> This is all within the user input range - any non-zero number turns  
> it on, zero turns it off - it passes the input on to the output.

>
>  From the Max Reference manual:
>
> Input	int	The number is sent out the outlet. If the number is not 0,  
> toggle displays an X, showing it is on. If it is 0, toggle is blank,  
> showing it is off.
>
> Output	int	A number received in the inlet is sent out the outlet. A  
> bang or a mouse click sends 1 or 0 out the outlet, depending on  
> whether toggle is being turned on or off.

>
>
> On Feb 6, 2007, at 9:07 AM, Mattijs Kneppers wrote:
>
> >
> > I think this behaviour is not intuitive. I expect that I can depend  
> > on the output of the interface object to be within the user input  
> > range.
> >
>
> ----
> Steven M. Miller
>
> Home 
> SFIFEM 
> Atrium Sound Space 
> OVOS 
>
>
>
>
----------------------------------------------------


> Hey, I'm not saying that toggle is buggy. I'm only saying that a user interface element has the primary goal to reflect the state of the program on the screen as well as possible. And I think it could do that better than it currently does, by limiting its output to 0 and 1.

So you may use a matrix control, with # as much as you need # button 

states. And if reflecting the state of the program is your only goal, 

Toggle means toggle between one state to another, not travel between 

different states. It's a boolean object and i think it's sexy.

> I don't think it can be changed, but well.. maybe it's nice input for future interface considerations.

>> On Feb 6, 2007, at 9:07 AM, Mattijs Kneppers wrote:

>>> I think this behaviour is not intuitive. I expect that I can depend 

>>> on the output of the interface object to be within the user input 

> ----------------------------------------------------

> Interactive audiovisual sampling soft- and hardware

> Hey, I'm not saying that toggle is buggy. I'm only saying that a user interface element has the primary goal to reflect the state of the program on the screen as well as possible. And I think it could do that better than it currently does, by limiting its output to 0 and 1.
>
So you may use a matrix control, with # as much as you need # button 
states. And if reflecting the state of the program is your only goal, 
use a numbox then...

Toggle means toggle between one state to another, not travel between 
different states. It's a boolean object and i think it's sexy.

f.e
> I don't think it can be changed, but well.. maybe it's nice input for future interface considerations.
>
> Cheers,
> Mattijs
>
>
>> On Feb 6, 2007, at 9:07 AM, Mattijs Kneppers wrote:
>>
>>
>>> I think this behaviour is not intuitive. I expect that I can depend  
>>> on the output of the interface object to be within the user input  
>>> range.
>>>
>>>
>> ----
>> Steven M. Miller
>>
>> Home 
>> SFIFEM 
>> Atrium Sound Space 
>> OVOS 
>>
>>
>>
>>
>>
> ----------------------------------------------------
>
>
> --
> SmadSteck - http://www.smadsteck.nl
> Interactive audiovisual sampling soft- and hardware
>
>
>


Quote: Peter Castine wrote on Tue, 06 February 2007 19:44

> On 6-Feb-2007, at 18:00, Mattijs Kneppers wrote:

> The extent to which toggle's behavior is confusing is inversely 

> proportional to how deeply your consciousness is imbued with C's 

You're right, toggle shows "input ? 1 : 0" and outputs the input. I use the open interpretation of 'boolean' in C often to save lines. But when it comes to interface elements I tend to literally believe what they say. C code officially doesn't promise anything from its appearance while toggle does.

> IOW: this is great for those who think C/C++ is the best programming 

> language ever to grace this planet. All a matter of taste (or lack 

> Peter Castine +--> Litter Power & Litter Bundle for Jitter

> Interface Building for |home | chez nous|

> Max/MSP Extremely cool |bei uns | i nostri|

Quote: Peter Castine wrote on Tue, 06 February 2007 19:44
----------------------------------------------------
> On 6-Feb-2007, at 18:00, Mattijs Kneppers wrote:
> > I does, but it shouldn't!
>
> The extent to which toggle's behavior is confusing is inversely  
> proportional to how deeply your consciousness is imbued with C's  
> bastard concept of "Boolean".

>
> IOW: this is great for those who think C/C++ is the best programming  
> language ever to grace this planet. All a matter of taste (or lack  
> thereof).
>
> --------------    http://www.bek.no/~pcastine/Litter/    -------------
> Peter Castine             +--> Litter Power & Litter Bundle for Jitter
>                                 Universal Binaries on the way
> iCE:  Sequencing,  Recording &
>        Interface  Building  for                   |home    | chez nous|
>        Max/MSP   Extremely cool                   |bei uns |  i nostri|
>        http://www.dspaudio.com/                   http://www.castine.de
>
>
>
----------------------------------------------------


Please excuse the grammatical rectification of the subject. At least 

we've now got syntax down, I won't start about semantics...

On 7-Feb-2007, at 10:04, Mattijs Kneppers wrote:

> I'm only saying that a user interface element has the primary goal 

> to reflect the state of the program on the screen as well as 

> possible. And I think it could do that better than it currently 

> does, by limiting its output to 0 and 1.

Again, from the perspective of a red-blooded C programmer, toggle's 

display reflects its state admirably. Zero is false, anything else is 

true. Conversely: false/off is zero; true/on is anything else.

One just needs the One True Religion in which the Holy Trinity is 

Brian K., Dennis R., and your compiler (which is probably not 

compliant, but when did religious fundamentalists ever worry about 

> I don't think it can be changed, but well.. maybe it's nice input 

I could imagine an Inspector for toggle with a 'Constrain Output to 

Canonical Values (Zero and One)' control. This would be a toggle (of 

course) sending, say, a 'constrain $1' message.

Of course, the default state would have to be 'constrain 0', and in 

five years' time there will be uncounted threads about "why is the 

damn default 'constrain state' for toggle off?"

There are days when I don't envy DDZ and his crew of merry pirates. 

Please excuse the grammatical rectification of the subject. At least  
we've now got syntax down, I won't start about semantics...

> I'm only saying that a user interface element has the primary goal  
> to reflect the state of the program on the screen as well as  
> possible. And I think it could do that better than it currently  
> does, by limiting its output to 0 and 1.

Again, from the perspective of a red-blooded C programmer, toggle's  
display reflects its state admirably. Zero is false, anything else is  
true. Conversely: false/off is zero; true/on is anything else.

One just needs the One True Religion in which the Holy Trinity is  
Brian K., Dennis R., and your compiler (which is probably not  
compliant, but when did religious fundamentalists ever worry about  
consistency?).

> I don't think it can be changed, but well.. maybe it's nice input  
> for future interface considerations.

I could imagine an Inspector for toggle with a 'Constrain Output to  
Canonical Values (Zero and One)' control. This would be a toggle (of  
course) sending, say, a 'constrain $1' message.

Of course, the default state would have to be 'constrain 0', and in  
five years' time there will be uncounted threads about "why is the  
damn default 'constrain state' for toggle off?"

There are days when I don't envy DDZ and his crew of merry pirates.  
Yo-ho-ho.

Quote: Peter Castine wrote on Wed, 07 February 2007 12:18

> Please excuse the grammatical rectification of the subject. At least 

> we've now got syntax down, I won't start about semantics...

Thanks! Please, PLEASE correct my english. Maybe it's this obsession for correct syntax, but I really hate language mistakes, especially if I'm the one that makes them.

> On 7-Feb-2007, at 10:04, Mattijs Kneppers wrote:

> > I'm only saying that a user interface element has the primary goal 

> > to reflect the state of the program on the screen as well as 

> > possible. And I think it could do that better than it currently 

> > does, by limiting its output to 0 and 1.

> Again, from the perspective of a red-blooded C programmer, toggle's 

> display reflects its state admirably. Zero is false, anything else is 

> true. Conversely: false/off is zero; true/on is anything else.

> One just needs the One True Religion in which the Holy Trinity is 

> Brian K., Dennis R., and your compiler (which is probably not 

> compliant, but when did religious fundamentalists ever worry about 

> > I don't think it can be changed, but well.. maybe it's nice input 

> I could imagine an Inspector for toggle with a 'Constrain Output to 

> Canonical Values (Zero and One)' control. This would be a toggle (of 

> course) sending, say, a 'constrain $1' message.

> Of course, the default state would have to be 'constrain 0', and in 

> five years' time there will be uncounted threads about "why is the 

> damn default 'constrain state' for toggle off?"

> There are days when I don't envy DDZ and his crew of merry pirates. 

Quote: Peter Castine wrote on Wed, 07 February 2007 12:18
----------------------------------------------------
> Please excuse the grammatical rectification of the subject. At least  
> we've now got syntax down, I won't start about semantics...
>

> On 7-Feb-2007, at 10:04, Mattijs Kneppers wrote:
>
> > I'm only saying that a user interface element has the primary goal  
> > to reflect the state of the program on the screen as well as  
> > possible. And I think it could do that better than it currently  
> > does, by limiting its output to 0 and 1.
>
> Again, from the perspective of a red-blooded C programmer, toggle's  
> display reflects its state admirably. Zero is false, anything else is  
> true. Conversely: false/off is zero; true/on is anything else.
>
> One just needs the One True Religion in which the Holy Trinity is  
> Brian K., Dennis R., and your compiler (which is probably not  
> compliant, but when did religious fundamentalists ever worry about  
> consistency?).
>
> It's all a matter of perspective.
>
> > I don't think it can be changed, but well.. maybe it's nice input  
> > for future interface considerations.
>
> I could imagine an Inspector for toggle with a 'Constrain Output to  
> Canonical Values (Zero and One)' control. This would be a toggle (of  
> course) sending, say, a 'constrain $1' message.
>
> Of course, the default state would have to be 'constrain 0', and in  
> five years' time there will be uncounted threads about "why is the  
> damn default 'constrain state' for toggle off?"
>
> There are days when I don't envy DDZ and his crew of merry pirates.  
> Yo-ho-ho.
>
> --------------    http://www.bek.no/~pcastine/Litter/    -------------
> Peter Castine             +--> Litter Power & Litter Bundle for Jitter
>                                 Universal Binaries on the way
> iCE:  Sequencing,  Recording &
>        Interface  Building  for                   |home    | chez nous|
>        Max/MSP   Extremely cool                   |bei uns |  i nostri|
>        http://www.dspaudio.com/                   http://www.castine.de
>
>
>
----------------------------------------------------


toggle doesn't act intuitive