oivindi

I have made a relatively simple sample player, and I have selected certain objects to appear in presentation mode.

However, I want to duplicate the way things look in presentation mode (I want to have at least eight of these sample players playing back in presentation mode).

If I duplicate a group of objects in presentation mode, I have no control over where the objects appear in patching mode - which makes patching mode a mess after I have made several copies in presentation mode.

Is there a way to control where objects appear in patching mode after they have been duplicated in presentation mode?

This is how things look after a few duplications (patching mode):

And this is how lovely it looks in presentation mode:

duplication-presentation-mode-and-placement

I know I'm not actually answering your question but you might want to save a single instance of the sample player patch to open in presentation mode and then use multiple [bpatcher]s to load them in your main patch.

I haven't really worked with bpatchers before, but I did some fooling around with it, and I think you might have led me on to something.

yep, anytime you have multiple copies of a group of objects with little or no changes, look into bpatcher. There are pros and cons to using them, but in a case like this they're mostly pros. You can use arguments to change some things for each instance.

Just have to remember to keep the file with the main patch, plus if you're using presets in the bpatcher, these are universal upon load (they'll all be the same as the master copy). If you change them while running the patch, you can add new ones to individual bpatchers, but these won't save on exit---you need to modify the master patch for this. The alternative is to use a pattrstorage on the main level, with @greedy 1. Then you can save slots which have different settings for each bpatcher.

Another nice trick which saves space, if your UI would be effective this way, is to stack them and use thispatcher scripting to select the active one (which one is on top and therefor can be clicked). bringtofront will work, you can use or something to select them. However in this case it looks like you want them spread out so you can access them all at once. So in this case, you benefit from being able to move them as single boxes, rather than a group of connected objects, which can get messy especially upon duplication.

Another nice trick which saves space, if your UI would be effective this way, is to stack them and use thispatcher scripting to select the active one (which one is on top and therefor can be clicked). bringtofront  will work, you can use  or something to select them. However in this case it looks like you want them spread out so you can access them all at once. So in this case, you benefit from being able to move them as single boxes, rather than a group of connected objects, which can get messy especially upon duplication.


Made a lovely-looking (relatively speaking) patch using bpatcher yesterday, which basically does exactly what I want - with a lot less hassle than with my first solution.

However ... the world of pattr is (also) unknown to me, and since the preset object won't work with bpatcher (at least as far as I can tell) I guess I have to use pattrstorage or something to that extent.

Made a lovely-looking (relatively speaking) patch using bpatcher yesterday, which basically does exactly what I want - with a lot less hassle than with my first solution. 

Ok, found the preset solution in this post - great!

https://cycling74.com/forums/index.php?t=msg&goto=175122&rid=0&srch=preset+bpatcher#msg_175122

This is a great way to do it. Just realize that the [preset] is only used as an interface object in this case, not actually "storing" anything except indices to the [pattrstorage]. So it's functioning in a different way than it normally does. It's a great addition to its capabilities, a lot more intuitive than "set #"..."store #"..."recall #" using number boxes and bangs.

In the past I've also used [preset] as a nice way to select integer indices, not as a storage object. If you hook up the [preset] to a dummy number box (so that it will only remember that one and not everything in the patch) and store presets in all the bubbles, then you can just click on bubbles to send out ints, which in turn trigger something else like an image file or sound clip. Still being able to shift-click is a little confusing, but you can have the "preset # when stored" outlet do something else too. With [tab] available now, this is less needed. And if you're using it with [pattrstorage], this isn't what you want either, but it's been handy for other things.

[pattrstorage] is the best, though sometimes I wish there were an easy way to keep the settings with the patch like [preset] can. Probably this is tricky though. So just remember to have that xml file wherever the patch goes.

Duplication, presentation mode and placement?