I seem to have found a bug or inconsistency in the behaviour of the preset object:

When a preset is recalled by inputting the preset number in its first inlet, the number doesn't come out the second outlet. The preset number only comes out the second outlet when a preset is recalled by clicking on the blobs in the object itself.

It should come out there in both situations, because in both cases a preset is recalled.

When a preset is recalled by inputting the preset number in its first inlet, the number doesn't come out the second outlet. The preset number only comes out the second outlet when a preset is recalled by clicking on the blobs in the object itself. 

bug-in-preset-object

And I too collided with this inconvenience though in max 4.6.3 it worked.

Ah, that would confirm that it is a bug rather than a change in functionality.

I can reproduce this, we'll have a look at it.

damn, i thought this was a feature and i've been using it. for quite a while now, can't remember since which version though. will it get 'fixed'? or could we have an 'option'? sorry, sometimes the users ask way too much (!).

It has been fixed. The expected behavior which existed in Max 4.x will be back. If you don't want the value to be sent out the outlet you'll have to patch a bit with a gate or something like that.

Great, just at the time I was searching the list for this strange behavior !

Great, just at the time I was searching the list for this strange behavior !
where can we find the fixed object ?
thanks


It'll be in the next incremental. Preset is part of the kernel.

Emmanuel, can you tell plz where I can find (link if it possible) fixed objects for MAX 5 ?

https://cycling74.com/downloads/incremental/

I really ment the next incremental version, aka Max 5.1.4. Preset is an internal (embed in the Max application itself).

this correction will mean i can count the number of presets. is there then a way to recognize that a present has been deleted by blob-clicking rather than by message? is there an easier way to count the number of active presets? i am asking this from the pointing of view that i am succeeding at [bad grammar, early in the morning of a late night]: to show that preset has great use--i have my students make a preset as soon as they start a patch, and we have a little (and obvious) trick to have our abstractions and bpatches have "preset talk." but i am quite interested in its limitations as a segue into pattr, and how important that whole family of storage is.

thanks for any help here.
peter (whincop)
lecturer, electronic music composition
composer etc.
MIT


For such kind of thing i would recommend using 

, as you can send various messages to query its states. You can still use 

For such kind of thing i would recommend using pattrstorage, as you can send various messages to query its states. You can still use preset as a remote UI for pattrstorage.


thanks, emmanuel. oddly, that's the smooth move i had planned for *next* week; i was trying to demonstrate to a bunch of MIT computer scientists things like lexical scope (pv, pvar, sneaking #0 up a level), how #0 doesn't go deeper than the next layer, and that preset can be a quick fix, but as with quick fixes, to extend it rather than seeking something different is not impossible, but time-consuming. embedding invites another bunch of difficulties, and advantages. (we even work on metacircular evalutors as a way to do true recursion, and finite state machines--much fun.) your suggestion is actually a tidy way of making the transition to pattr, which will be extremely foreign to the non-computer scientists. thanks for the reply. peter

Bug in Preset object