Preset 4th Outlet Doesn't Work
As the title states, the 4th outlet does not work. It's supposed to send the integer number of the preset that just got stored, but nothing comes out.
This is even true in the help file - I can set a break watchpoint, store a new preset (or overwrite an old) and nothing shows up on that outlet. The outlet that sends out an int when a preset is recalled works fine, but this one doesn't.
Am I doing something wrong, or is it broken?
preset number when stored: only as you shift-click a slot.
Whereas 2nd outlet gives preset number when recalled.
Huh, look at that. What an odd way to have that work. Thank you Florian!
So if I want a named preset, I have to do that separately OR keep track of the indices somewhere else when programmatically storing presets.
I basically want to give the user a textedit field for the name of the preset, then have an automated routine to prepend the number and send it to the [preset~].
If there's a better way than what I've got here, I'd be open to suggestions.
adjust preset attributes as needed.
keep textedit as set
It's worth noticing that Source audio solution doesn't actually set preset names, but save the content of the [textedit] instead. The main difference is that the name won't appear in [preset] when hovering the preset slots, but will appear in [textedit] instead.
Another alternative I can suggest is to use [pattrstorage] + the jsui [preset] re-creation I build that allows you to edit preset names directly into the interface (using a automatically shown/hidden [textedit]). More info here.
I've seen many suggestions to use [pattrstorage] when dealing with presets, and while I would like to I don't think it works with the way we have our patcher set up. Maybe I'm wrong though:
We have one main patcher with many [bpatcher]s, with further nested [bpatcher]s, [p]s, and externals. In order to save them with [pattrstorage], wouldn't I need to go into each lowest level patcher, add a [pattrstorage] and an [autopattr], then somehow link all the [pattrstorage]s together?
Maybe I'm just not thinking about it correctly, but adding these presets with a wireless [s] and [r] on each one feels much cleaner.
a) inclusion of objects and exclusion of objects is either-or.
b) i remember that [preset] does not work across patcher levels i.e. you can not put it into an abstraction. if that is still the case, it makes sense that s/r or using a [gate] also does not work.
same with the magic [grab] connection.
strange enough that it works for tapout~.
We have one main patcher with many [bpatcher]s, with further nested [bpatcher]s, [p]s, and externals. In order to save them with [pattrstorage], wouldn't I need to go into each lowest level patcher, add a [pattrstorage] and an [autopattr], then somehow link all the [pattrstorage]s together?
Nope, you would just need one [pattrstorage] in your top-level patcher, but yes, one [autopattr] per patcher/bpatcher/abstraction.
But since your patch is already set up for [preset], I assume you already have those [autopattr] in place, and all you would need to do is to create one [pattrstorage name] (replace "name" by whatever you want) in your top-level patcher, and set the @pattrstorage attribute of your existing [preset] to that name.