posssu

I can't seem to find anything like "current value" from the attributes of a number box or a slider, so I can't freeze it.

So far the only way I found to do this is to loadbang a message, which will then set the value of a number box.

However, is there any way to set the initial value within the number box or a slider/knob element to make the patch cleaner and to avoid using loadbang?

setting-initial-value-of-a-number-box-or-a-sliderknob

they have lots of features for getting and setting values to numberboxes/sliders/knobs...

did you know about pattr objects?
they have lots of features for getting and setting values to numberboxes/sliders/knobs...

quickest way: just place [autopattr @autoname 1] in your patch like this and it will save the actual state with the patch:

without the autoname attribute of autopattr you have to name your objects manualy like this:

hi,
quickest way: just place [autopattr @autoname 1] in your patch like this and it will save the actual state with the patch:

you can of course use the objects suggested above or even the 

but you might hate that later when you biuld bigger projects,

because you can not really control the load order with those.

you can of course use the objects suggested above or even the 
good old [preset] object. 

but you might hate that later when you biuld bigger projects,
because you can not really control the load order with those.

Roman Thilenius wrote on Fri, 07 August 2009 19:26

The only thing wrong with messages (and probably with the other solutions above too) is that they take space. I was looking if there was some way to set the initial value as an attribute. It's weird, since for example sliders have "min value" and "max value". Why not initial value? Same with number box - since they all have attributes, why not allow setting initial value there to save space.

Roman Thilenius wrote on Fri, 07 August 2009 19:26
(whats wrong with sending messages?)

The only thing wrong with messages (and probably with the other solutions above too) is that they take space. I was looking if there was some way to set the initial value as an attribute. It's weird, since for example sliders have "min value" and "max value". Why not initial value? Same with number box - since they all have attributes, why not allow setting initial value there to save space.


i think you can control the load order in pattrstorage setting priorities...

I was just checking out the Live objects that will be available with Max4Live - in fact they seem to have initial value (

https://cycling74.com/images/articles/creatingdevices_dz/ss5.png

) Maybe it'll come to native objects as well.

I was just checking out the Live objects that will be available with Max4Live - in fact they seem to have initial value (https://cycling74.com/images/articles/creatingdevices_dz/ss5.png) Maybe it'll come to native objects as well.


posssu wrote on Fri, 07 August 2009 21:13

It's weird, since for example sliders have "min value" and "max value". Why not initial value?

my guess is that the idea has always been that an application

or bigger patch will either have no default setting or some

and if it had custom automation/presets there is no need 

for an initial state for individual objects and so they just 

made all gui objects using the low limit as initial.

another thing is that gui objects can not take arguments,

and this is basically what you are aksing for, because a

init value via inspector brakes some rules about how the 

[i] can be initialised by [i 5], [flonum] can not.

different thing, but yeah, then why not also for flonum ...

if you have a faster computer and dont need max4 backwards 

compatibility, putting flonum into a bpatcher would be the

easiest and fastest way to build a custom flonum which can 

be initialised, is that an option for you?

posssu wrote on Fri, 07 August 2009 21:13It's weird, since for example sliders have "min value" and "max value". Why not initial value?

my guess is that the idea has always been that an application
or bigger patch will either have no default setting or some
kind of custom automation/ presets. 
and if  it had custom automation/presets there is no need 
for an initial state for individual objects and so they just 
made all gui objects using the low limit as initial.

another thing is that gui objects can not take arguments,
and this is basically what you are aksing for, because a
init value via inspector brakes some rules about how the 
inspector is intended to work.

then again, [bpatcher] does take arguments, a bit a 
different thing, but yeah, then why not also for flonum ...

if you have a faster computer and dont need max4 backwards 
compatibility, putting flonum into a bpatcher would be the
easiest and fastest way to build a custom flonum which can 
be initialised, is that an option for you?

The reason why live GUI objects from MfL will have an initial attribute is that they're linked to the automation. So basically they have a preset mechanism associated.

That's not the case of regular Max objects, so I would rather use (auto)pattr/preset or a simple loadmess to initialize the value to whatever you want.

The reason why live GUI objects from MfL will have an initial attribute is that they're linked to the automation. So basically they have a preset mechanism associated.
That's not the case of regular Max objects, so I would rather use (auto)pattr/preset or a simple loadmess to initialize the value to whatever you want.


Setting initial value of a number box or a slider/knob?