The current implementation of presets in Jamoma is the simple system where by values are stored and recalled by number or name. A preset file may contain multiple presets which may be stored or recalled. There a number of new features, requests, and possible extensions to the system for consideration. This includes a couple of item in the Sourceforge Feature Request Tracker:

http://sourceforge.net/tracker/index.php?func=detail&aid=1684253&group_id=78108&atid=552173

http://sourceforge.net/tracker/index.php?func=detail&aid=1695773&group_id=78108&atid=552173

This green paper page aims to summarize all of the issues on the table for consideration.

---

This is a short dialog from the jamoma-devel list from Pascal:

Having been pattr-addict with Z for a while, I have some ideas on the  
question :

1/ with PSTO, there is the message (pattr-name):active $1 that we can  
send to PSTO to determine if a pattr is active or not in the preset- 
recalling....
In Z I have a toggle for a kind of "recall-safe" function, only  
applying to volume and fx sends... (which of course is prioritized in  
such a way that it is recalled before the volume and sends.)
Typically I turn on the recall-safe function (sending active 0for tis  
pattr to PSTO) when the volume (or send) is handled manually, as a  
parameter for play...
Otherwise, it's also very handy that the volume can be recalled with  
the presets.... and in fact, in Z, it's absolutely necessary !

I was thinking to generalize this for all parameters when they are  
used as a mapper's output (which means they are played), in Jamoma...  
which isnt yet implemented... It could avoid having leaps when  
you're playing with a parameter while passing from a preset to the  
other...

2 /It can be dangerous to have mute and bypass as presettable  
parameters, in this kind of usage (pattr-like...), as you seem to  
warn...
But it can also be useful also sometimes, because you can decide that  
this or that module is muted or bypassed for this (global)-preset...

___

Finally, all this depends on how one uses the presets,
and in which combination with PSTO and jmod.cuelist, i.e. how one  
decides to build his unfolding of parameters in time...

The idea of having an attribute, like @preset_enable or something  
sounds good to me.
it could then be accessible remotely, using the message  
this_parameter:preset_enable $1...

Then we could decide that for all general /audio functions it could  
be set as 0 by default,
but that it could also be set for each other parameter in the way  
that the module creator is inclined to...

Hope this helps...

Best,

p


___

By the way, there's something that I wanted to ask for a while :
could it be possible to have the preset number of a module  
pattrified, so that we could access it from a PSTO ?
More or less, I was thinking about something like PSTO's 'greedy'  
mode, which allows to handle data individually for each parameter, or  
globally as a module's state...
Of course, then we have to see how this combines with all parameters  
being recalled by the same PSTO (the best would be that it could be  
avoided)... because I don't think we can disable pattr (for the  
module's parameters) like that .... or is it possible in  
jcom.parameter ?
Is this clear ? I'm not sure...
Anyway, this is no top-priority... and I think I'll have to think a  
bit more about all this, but I just wanted to know if this seems  
feasible, or not at all ??


Le 6 janv. 07 à 19:53, Timothy Place a écrit :

I've been working today on porting some of my old modules to the new
core.  Presets in Jade 1.1 were very much a manual module-by-module
implementation rather than an organized system.  One issue that comes
up is that if you have a lot of presets for an audio module, then
those presets control the gain parameter for the module.

Would it make sense to add an attribute to parameters such as gain,
mute, and bypass to ensure that they are not changed by preset
recalls (unless the preset is named default)?

What do you all think?
    Tim

---

We also have issues surrounding the creation of external interfaces to Jamoma's preset system. The current system was built on the idea that the preset system is essentially private to a module. However there is desire to create additional interfaces (both inside of modules and outside of them) for doing things like removing presets, adding them, updating them, duplicating or copying them, etc. Some snippets of email on jamoma-devel follow... Pascal writes:

so, concerning the preset stuff, I agree that we should find a GUI solution for storing/copying/deleting presets.
The list of presets is already included in the topleft menu.
I would recommend just adding a "store as current preset" item
and maybe another "manage presets" item that would make a little UI pop up (something like a of dialog patch included in jcom.gui....) allowing one to save the current state as some other preset (including naming it), copying (which is just basically storing it to another position...) and deleting... etc...

Here is an email correspondance with Yacine:

some of you might remember I was working on a sequencer.
what I had in mined, when the basic sequencer worked, was first to have gui to store and recall presets of a 32 step sequence.
I did something that works like the the good old preset object (shift click to save and click to recall for backward compatibility with my own brain processes) just with message boxes that are colored if the corresponding slot is used.
I wanted those color to update every-time saving a new preset and when loading presets from an xml file, it's the reason why I thought a flag attribute would be better than a dump message, though if the dump can be triggered by a successfully_loaded_settings message or something, this is also fine for me.
another reason besides the coloring for keeping a trace of which slots are in use is there is a weired bug happening when trying to recall an invalid preset, part of dsp process are frozen until max is restarted (i ve just submitted this one to the tracker)
the next step which I m working on now is to have n virtual pages of those 32 steps that could be looped for example and easily accessed, so this is like a second dimension in the array of presets.
I think I need n temp_preset_(1 to n) to work with which should auto_save each time recalling the next virtual page.
this is where I need the /preset/copy feature to copy pages and to save to a non_temp_preset_(1 to n) 
from another point of view, the virtual pages could be stored in a [jcom.parameter @type msg_list] when only showing a part of the list in the matrix control of the module but the reason I prefer the presets is the 500 and something limit of the msg_list type and I would prefer that n has no limit.

I hope I made myself clear enough now.

what do you guys think?
some want to have a look at the patches?

BTW, I didn't post any comment on my thoughts about the workshop that was because I was way too busy working on my modules, Jamoma is now a central tool in my work, I feel like its modularity base will change the way I patch from now on,
and I want to say a big THANK YOU to all the people involved in this project.
and special thanks to the GMEA and especially to Pascal for organizing the workshop and for inviting iMAL's people to Alby.

//yac


On Apr 5, 2007, at 3:23 AM, yacine sebti wrote:

i m implementing a gui to handel the presets from within a module, I
thought of asking for something like a preset/dump_flag to the
[jcom.hub] to receive the preset list every time it's updated...but I
found a workaround adding an output to the [jcom.guy] to route the
NEW_PRESETS and NEW_PRESETS_START messages , could this be
implemented in the official release? or maybe only adding an outlet
to make what comes out of [jcom.remote __GUI__] available in the
modules could serve more purposes and give a more general solution.

On 06-avr.-07, at 16:17, Timothy Place wrote:

I think a better way to do this would be to change the existing / 
presets/post message to the hub into /presets/dump etc.  This would  
be consistent with how query a module for parameters and other  
information, and would allow for preset information to be harvested  
from a Max patch outside of a module.

As Pascal suggested, on this list at least, it is super helpful to  
know what the final goal is.   Trond has mentioned adding this to the  
feature tracker.  Has anyone opened a feature tracker for this issue  
yet?

Thanks,
    Tim

---

So we need the following, at least:

/preset/remove
/preset/copy
/preset/rename ?
/presets/names/get (check with other messages for namespace)