Duplicate track - right click context entry

I would do it this way:

1. Phrase >> Copy
2. New Instrument with Same Sound
3. Phrase >> Paste

However, this will not copy phrases in other containers.

The concept "Track" does not exists (in the sense of some selectable object that spans across the entire arrangement). An arrangement rather is a tree of individual phrases that are assigned to instruments.

+1. Semantics aside, I think there should be a way to duplicate an instrument and all data contained within.

SO what happens when the part for the instrument is split across 70 or 80 containers (which is about what I've been using)?

Do you go into each container one by one and copy paste?

In theory, yes. However, I doubt this is a realistic, let alone frequent situation.

Although some menu item like "Instrument >> New With Same Content Across All Containers" would be simple to implement, I dont see the workflow situation that would benefit from populating the entire nested hierarchy of containers with a copy of all phrases to a new instrument. If you could point out a couple typical applications, that would be helpful.

On the other hand, adding menu items for every thinkable feature (and combinations of existing features) inevitably leads to a bloated and redundant menu forest like that of Reaper, for example, and this is something we definitely want to avoid.

A rule of thumb for developers roughly says: If a menu contains more than, say, fifteen items, you messed up your application design (don't remember exactly, and I'm not especially religious with that, but you get the idea).

Yes, the container structure is a new concept that can be a challenge to learn.

I'm afraid I don't understand what you mean by saying "duplicate containers on a track", as containers are not placed on tracks. So I wonder if you might confuse something.

Actually it works exactly the other way around. All containers always include all instruments ("tracks"), of which one or more instruments may have parameters assigned, or not. The structure view shows how the containers relate to each other.

You probably just want to duplicate a phrase inside a container?

I just want to be able to copy all the phrase on the instrument and duplicate it onto another line withot going through all the steps I mentioned.

I think that's what Andre was talking about when he suggested he could add an item like "Instrument >> New With Same Content Across All Containers".

I can see that being very useful in case you mention, sonomusic:

This for instance would be if I had a lead violin line and I wanted to duplicate it for 2nd violins and then begin moving it down to get interesting harmonies.

If all we're going to have are discussions on my terminology let's just forget it. I'll work with it the way it is.

Its hard to communicate when concepts are abstract. If we're all patient with each other, eventually we'll be on the same page. I don't mean to scold though. :)

It feels like I'm commanding a spaceship with a DOS interface.

That's a great way of describing working with Synfire. However, although I haven't experienced major work-flow issues, I welcome more usability enhancements.

On the other hand, adding menu items for every thinkable feature (and combinations of existing features) inevitably leads to a bloated and redundant menu forest like that of Reaper, for example, and this is something we definitely want to avoid.

A rule of thumb for developers roughly says: If a menu contains more than, say, fifteen items, you messed up your application design (don't remember exactly, and I'm not especially religious with that, but you get the idea).

I disagree with the fact that Reaper is bloated. I think they a now allow you to completely customize the menus to have as many items as want (or don't). Plus, almost everything can be mapped to a key-command. That is totally not bloat. Its quiet helpful.

Just my two cents. :)

That feature would take five minutes to implement. If there is a demand for it, I'll do it.

I still wonder if it makes sense to blindly populate, say, 50 nested containers spanning 15 minutes of music with duplicates of all an instrument's phrases. One would likely visit most of the containers anyway in order to delete duplicates where they are not wanted.

There should at least be some means for limiting the scope of the duplication. Would it be ok to multi-select the desired containers first?

To me, it sounds like something I would use--especially in the case sonomusic suggested. But its honestly hard to know for sure. That's why I vote to add it.

How about duplicating only the selected containers if any are selected; otherwise, duplicate all?

I still wonder if it makes sense to blindly populate, say, 50 nested containers spanning 15 minutes of music with duplicates of all an instrument's phrases. One would likely visit most of the containers anyway in order to delete duplicates where they are not wanted.

Again, its hard to know what features will necessarily be useful, but that's part of the beauty of it. As we all have different working methods, the more work-flow options, the better, IMO.

If you guys start adding compressors and EQs, then I would start to holler, "bloat". :) But, IMO, add everything you think is useful workflow-wise.

I've added the feature. Let's see if it proves to be useful.

Thanks Andre. You guys rock. I'll try to test it out in the coming weeks. We're moving, so it may be a minute before I can get to it. :)

Thanks for providing some insight into your workflow. Very interesting and helpful.

I do tend to work with smaller sections say 8-32 bars. Then when I get it the way I want I move it into a larger project with other containers.

[quote]I've attached a demo I did with the demo before I bought the program.
Wow. What sound library are you using? :listen:

Yeah, nice work, sonomusic.

I'm checking this out now. Is this implemented by right-clicking an instrument and choosing, "Duplicate"? That seems to duplicate the instrument with its contained data. I don't remember if that option was there before, but it seems very useful.

Thanks!