Multiple structures in arrangement

Is what you envision just different perspectives on the same container hierarchy, or genuine alternative arrangements?

How would you use it?

Sounds interesting. But definitely a big change with wide ranging implications.

Except for the aliasing across arrangements, this is what the global rack was meant for actually. Many small arrangements using the same sounds. Albeit not the same (private) devices. So yes, this would be more comfortable.

The way to do this now is you duplicate the arrangement, experiment with the copy, then copy/paste what you want to keep back into the main arrangement.

Sharing private devices outside their scope (document) is currently not possible. The device ID is unique only within that scope. Only global devices can be shared.

I'm glad the whole device thing finally works, so very reluctant to touch anything related to devices at this time.

The earlier suggestion of having multiple arrangements on tabs that all have access to the same sounds (global and private rack) is not feasible?

(https://users.cognitone.com/topic/container-import)

As long as it's a single document with one private rack, no problem.

In fact, the Snippets already are a separate container hierarchy in the same document.

As long as it's a single document with one private rack, no problem.

I would greatly appreciate that. Would make things much easier for me. As I've said before, when I'm working on a project, I'm always dealing with a whole bunch of individual arrangement files, but they're all based on the same sounds. It would be nice to have all that in a single project file.  And it would hopefully simplify the process of exchanging containers between subarrangements again.

The challenge is not so much with internal data structure (although an arbitrary number of content branches adds complexity). There are file migration issues and other dependencies that pop up when a new docment format is introduced. And then there's another layer of UI with tabs that need to fit in somewhere, new commands to create, move, delete tabs, all that stuff. Overall it's a disruptive change.

I like the idea very much. But we don't have the capacity to implement it anytime soon.

You can use the Snippets grid as a place to put all sorts of experimental containers aside. They share the same instruments. Nesting is not possible though.

Snippets are also great for A/B testing as you can switch them live.

Of course, I definitely appreciate the new snippets. But because of the, as you say yourself, missing nesting functionality, it is only of limited use for the topic discussed here. For clarification, a few more words about use cases:

• Experimental editing of an arrangement: When you continue to work on an existing arrangement, you never know whether the next steps will improve the track or not. If not, there is the Undo function. But this has the disadvantage that you often don't know how many steps you have to go back and whether you will exactly reach the previous state again. It would be better to simply open a new Arrangement tab for such experiments (envisioned command: "Open arrangement in new tab" ). Then you could also perform instantaneous A/B comparisons.
• Creating variations of arrangement sections: It can of course also be done within one arragement (via snapshots, etc.), but if you want to create variations from an existing song section, I prefer to do it in a completely new arrangement. So far I have to create a file copy of the existing arrangement and make the changes there..
• Creating of new structures based on containers of an existing arrangement: That's actually the main point, as this has now become very cumbersome since the container copy-paste function across arrangements is no longer available in Synfire 2: If I have an existing arrangement, which for example represents the middle part of a song, and want to create further parts of the song (intro, outro, etc.) based on it, so far I have done this by opening a new empty arrangement file and copying a few suitable containers from the basic arrangement into it and then rearranging it. This workflow is now virtually impossible. I have workarounds, but with the envisioned new "tab functionality", I would then simply open a new empty arrangement tab and reapply the same workflow as described above.

Thanks for the input.

Maybe "Restore Points" could be helpful? That's a snapshot of the current arrangement to which you can return at any time, no matter how many Undos have been saved in between.

As long as the entire root container is backed up, maintaining integrity is easy. Doing it on a per-container basis would be even more useful, but I'm afraid it would also be less robust (imagine instruments are removed, or the originals of aliases are modified or removed).

Modeling creative workflows is really hard. Anything beyond Undo is rarely seen in media applications.

Maybe "Restore Points" could be helpful? 

Yes, that would also be helpful. Or a list of undo-steps where you can select the desired project state from the list. Like in Cubase (or other software, such as Word, etc.). 

Anything beyond Undo is rarely seen in media applications.

Well, tabs for multiple worksheets is even seen in Excel. And that software is certainly not an outstanding example of advanced programming science  :)

Anyway, of course I understand that there are other priorities at the moment. 

@juergen I just try to better understand the workflow you are aiming at: if you would be able to copy nested containers between multiple independent arrangement files, would that address what you need?

I understand that it has been discussed before that this feature is gone and likely gone for good. Nevertheless, perhaps some limited version of that feature could be recreated again, e.g., to allow copying nested containers between independent arrangements that share exactly the same instruments (if it is possible by Synfire to recognise this somehow, as these instruments will perhaps differ nevertheless in IDs).

I am only bringing this up as an idea, because implementing some data structure copying between arrangements -- as complex as it might be to implement -- might still be more simple to realise than introducing multiple arrangement tabs. For the copying between arrangements likely no additional GUI elements would need to be introduced, but these would be needed for the tabs.

Anyway, I understand that nothing of this is likely to be realised any time soon, as the priority is currently to finally release version 2 officially.

>  so far I have done this by opening a new empty arrangement file and copying a few suitable containers from the basic arrangement into it and then rearranging it. This workflow is now virtually impossible. I have workarounds...

Would you mind describing your workarounds? It seems to me that being able to reuse and play around with (creating variations before deciding on which variation to use in the end) not only individual figures and phrases (supported by libraries) but also larger structures and polyphonic arrangements like a sequence of sections (nested containers) would be extremely useful if not even essential for building large(r) forms.

Nevertheless, perhaps some limited version of that feature could be recreated again, e.g., to allow copying nested containers between independent arrangements that share exactly the same instruments

Yes, it's all about the exchange of nested containers between different arrangements. A solution that works only for arrangements that share exactly the same instruments would indeed be sufficient for me. 

However, I don't think it's a good idea to implement a solution that only works under certain circumstances and constraints. I don't want a special feature that only works for me. If it is implemented, it really should work in general. Otherwise it only leads to bad user experiences.

Would you mind describing your workarounds? 

Instead of copying containers from one arrangement to an empty new arragement you can also do it of course vice versa: Make a full copy of the original arrangement file and delete the undesired containers in the new file. This way only the containers you wanted to copy will then remain in the new file. 

Things only get tricky if you want to copy containers from several different source arrangements together into a new arrangement. Then you won't get around an instrument-by-instrument copy. 

But as you certainly know: Dealing with software products means dealing with a world of workarounds.

The challenge is referential integrity.

The Excel example is quite instructive (Apple's Numbers as well). If you edit, resize or delete a table on one sheet, references to its cells on other sheets will be broken. The spreadsheet apps have a way to deal with broken references: Simply label them as broken and let the user deal with the mess. I happen to maintain an extensive multi-page spreadsheet for archery (bow/arrow configuration) and can tell you: It's a pain.

Imagine an alias container labeled "broken" and the user in charge of looking for broken aliases, re-assigning originals, or deleting them. Not nice, but maybe acceptable. The real hard part however is references to instruments and sounds (rack modules). We are not there yet (any maybe never will), but imagine parameter aliases. Or references to parameters generated elsewhere.

With network-like data like this, copy/paste becomes really complex.

> Things only get tricky if you want to copy containers from several different source arrangements together into a new arrangement. Then you won't get around an instrument-by-instrument copy. 

Thanks for sharing some of your workflow. I think it is actually not too bad if we need to manually recreate the relevant container structure, ensure the necessary instruments are there and then copy over the actual musical material track by track (though this gets of cource more and more tricky the more nested the container structure to copy is).

However, what I find problematic is that it is not even possibly to copy all the musical material for a single track in a single container in one step. If your music makes use of multiple parameters, then you basically have to copy separately each parameter of each track of each container!

I appreciate and highly value that it is possible to process incl. copy & paste each parameter separately. However, so far I did not find a way to copy all parameters of some track in one go.  Did I perhaps miss something?

 If you edit, resize or delete a table on one sheet, references to its cells on other sheets will be broken. 

I don't think that would be an issue here, as there won't be any references between the arrangements on different tabs. I do not require alias containers referenced across arrangements. That would certainly go too far. If someone tries to copy an alias container into a new arrangement, simply the referenced original container is copied instead.

However, what I find problematic is that it is not even possibly to copy all the musical material for a single track in a single container in one step.

That actually is possible, I guess. But you have to do it instrument by instrument and you have to go through the sound setup wizard each time (as far as I remember). It's not a real option if you are in the experimentation phase and just want to try something quickly. 

Of course can you copy all parameters in one step: Select an instrument header on the track sheet and do Copy, Cut, Paste.

Selecting an instrument header puts the phrase in the focus of keyboard and Edit menu.

Selecting a parameter outlet does so for a single parameter.

Selecting a container does so for a container, etc.

This focus thing works for almost every selectable object.

If someone tries to copy an alias container into a new arrangement, simply the referenced original container is copied instead.

That would be very limited. You will want to build a structure with aliases of containers from other structures (tabs). Otherwise what's the point of having merely a physical clipboard?

> Of course can you copy all parameters in one step: Select an instrument header on the track sheet and do Copy, Cut, Paste.

Ah, great: so it is possible to copy all parameters from one track in a source container, and then copy it into some target container in another arragement. Thanks!

It seems it is not possible to only copy in one step all the data of a selected time span of a container, it is always all the data of a track in a container. In particular, the pasting would overwrite any pre-existing data in that container (e.g., the newly inserted data cannot simply start in the middle of the container). Anyway, with some pre-planning this is perhaps reasonably flexible, as one can have containers start and end anywere.

You will want to build a structure with aliases of containers from other structures (tabs). 

I want to build up a new structure based on some already existing structures without affecting the existing structures. For this, I don't necessarily see a need for cross-arrangement references in form of container aliases. On the contrary, that would only make things completely confusing. For example, if I have different arrangements spread across 5 tabs and each arrangement can have alias references from anywhere from the other arrangements, that would be completely unmanageable. No, each tab would have to be a self-contained arrangement with no cross-references. The only connection between them would be the sound setup, which applies equally to all individual arrangements.

That would be very limited. 

I admit that we're not talking about overwhelming super functionality here, but it's still something that we don't have now and would definitely be useful.

It seems it is not possible to only copy in one step all the data of a selected time span of a container

Multiple parameters constitute a phrase and a phrase always starts from the beginning of a container. Only at the parameter level can you insert something later in the phrase.

You can however select a span and make a new phrase in the embedded library (Command-E). Then drop that phrase anywhere. If the phrase consists of multiple parameters, these should all be inserted at the offset you drop the phrase. If not, it's probably a bug.

I deliberate say "probably", because inserting multi-parameter phrases anywhere in the middle of a container is a very heuristic procedure with lots of exceptions and edge cases:

• Some parameters in a multi-parameter phrase are ignored (Tempo, Scheme, Harmony, Volume, Pan, etc) unless you grab them from the Parameter tab, signalling that you want to replace them in the arrangement. If a phrase however contains only one of these parameters, it is considered a single-parameter phrase and the parameter is inserted no matter what.
• Some parameters are inserted only if they are not already present (Interpretation)
• Inserting a parameter at an offset position causes all values before that position to be undefined. Every parameter type and interpolation mode has different rules how to deal with undefined values.

I could go on for while, but you get the idea how hairy this topic is.

There's a rule of thumb:

When you want something to start in the middle of a container, insert a child container.

Actually, "something new begins" "is the very definition of container.

> When you want something to start in the middle of a container, insert a child container.

Thank you for all this feedback. I understand that this is the design of Synfire.

I am probably still at a stage where I am exploring what Synfire containers can actually express. For example, in music there can be cases where there are extended gray zones of something old not quite finished yet and something new about to start (e.g., some new material announced very briefly -- perhaps just a single accent -- way before its actual arrival and by and by those announcements get denser until the new material takes over; or some main material is A forms the foreground, and then some material B enters as a counterpoint while A continues its development). I understand that Synfire containers can be nested, but I am still in the process of exploring how to best express blurred formal boundries with it, where additional nested containers are useful and where perhaps they may just overcomplicate matters for me.   

If you stich together a long Figure (e.g. 8m, 16m length) that includes some development (things sprayed-in that anticipate something new), that's fine. You don't need a new container for every nuance. Just drop short phrases in a row to make a gradual build-up or add some variation.

A child container is useful when, for example, one or more instruments start or stop playing at the same time, or a theme changes significantly, or Intrepretation settings change.

I have seen users moving spans inside extremely long Figures around to achieve this structural arranging. That's a red flag.