Concept Art - Ideas for Synfire 3

There is a lot of study in that, nicely done.
The feasibility of Synfire 3 should be investigated.
Is also thinking about using multiple instruments in 1 container whether that is clearly visible in the arrangement? 
The advantage of this is that the container structure becomes more organized. 
In the Overview tab you can see how the arrangement is structured which was newly introduced in Synfire 2 and it works well.
I thought there was a setting in Synfire to see what the content ( what instruments) of the container is?  

note: in the overview screen : the container name is noted 

I'm going to take more time to look over your proposals with more scrutiny, but I like many of the suggestions I see so far. Like you, I use Studio One as my main DAW. So I appreciate how you've taken the look and some of the most popular features of Studio One and brought them into Synfire. It may be a simple think, but an editable piano roll view would be much appreciated. Of course, Synfire 3 seems like a long way off at this moment. Were not even at 2.5 yet. I'm curious to see what new parameters and factories Andre is working on for the near future. But this is a good vision of what could be work towards by the time we get to version 3.

That design looks much more DAW-like (which is not a bad thing as most users are familiar with that). The overall look and colors however won't change that dramatically, but I spotted some nice design elements.

The idea of having separate parameter views for Figure and other parameters has been on my wish list for a long time. It somewhat resembles automation lanes. It comes with new challenges, but that's probably solvable.

Make it easier to create songs by eliminating the complexity of multiple instruments in containers.

I understand what many users want is a "DAW with Figures". I can imagine  Synfire Sparks working like that. We need to be careful though, not to reduce a dynamic prototyping system to merely another DAW with a chord track.

Arranging individual phrases on tracks is intuitive at first. But it makes working with aliases and nested parts harder (e.g. parts with their own Harmony, Scheme, Tempo, phrases, and child containers that introduce temporary changes). Non-destructive prototyping would be all but gone.

For pop songs and dance tracks this is fine. For arrangements with structure, it is a return to the static times. 

The concept is design to support both ways and you can switch from Tracks to Container-View anytime.

Overview is supposed to eventually become a "Tracks" view. It can be further improved and maybe re-labeled. Adding and moving phrases is not yet possible (and a challenge when there's already a container structure in place). It is likely that once there are containers with multiple instruments, the tracks mode will become read-only as it is now.

It's a challenge to reconcile the two modes within a single program.

What can be added is that it is already absolutely possible to operate Synfire with a track based workflow approach. Nobody forces you to store multi-instrument phrases in a single container. You are free to assign only one instrument to each container and arrange the containers in a "track-like" way. Then add a nice chord track container on top and the DAW view is complete. This is what it might look like:

To know if multiple instruments are assigned to a container, Synfire could also note this in the container anyway.
How a container will automatically record this which instruments are in a container?
Little space also in a container to write anything.
Manually you could set the track numbers or just set an indication that it is a multi instrument container 
- Multi
As soon as you start using multiple instruments in a container mark the container as "multi".
Would be even nicer (instead of text) if there is a visual sign on the container so you can immediately see in the container structure that is a multi -instrument container  

Fortunately, Synfire 2 introduced the overview screen
In Synfire 1 it was impossible to derive an idea from the container structure, how the arrangement was built.
But fortunately that has all changed and if a multi instrument container can now easily be recognized in the container structure, the overview screen can also be of service.
For example, if in an orchestral arrangement you have a container with brass written on it, then you just assume that there are multiple brass instruments in the container, but that doesn't have to be the case.
So a multi-instrument icon on the container would provide clarity

In general I wonder how many users work like that and use multiple instruments per container?

For orkestral composing 

Look at the tutorial and  example files for orchestral composing from Cognitone 

I wonder how many users work like that and use multiple instruments per container?

Almost everyone, I would guess. The song templates and tutorials all point to that workflow. Repeating parts (aliases) and resizing them is super easy. No need to move a lot of individual "Regions" around manually. And nothing to worry about if containers overlap or conflict with each other - Synfire sorts that out automatically.

it is already absolutely possible to operate Synfire with a track based workflow approach

When you first brought this up it was eye opening to me. I never thought of building a structure this way. Clever solution. But your example also illustrates where the approach has limits. What if you want to insert a part in the middle? Or shorten a previous section? Or repeat a section later on?

There is no way to group these child containers across "tracks" any more.

This layout is probably best for short and linear arrangements with only a single part, like a 30 sec. ad clip, a jingle or an audio logo. Or an ambient atmosphere.

For me, the current container concept is a core element of Synfire. It is essential that a container can contain data for a single instrument, for a group of instruments or for all instruments, or only parameters or combinations of all kinds. This is - together with the "data inheritance" from top to bottom - the crucial point. 

This concept should not be pushed into the background. The sooner a new user comes into contact with this concept and becomes familiar with it (and gets the tracks out of their head), the better. In my opinion, it should therefore already be included in Sparks in any case.

I don't do this but grouping them into a container to keep them in a bundle

That's basically what a container already does for you: Group multiple phrases. 

I think the confusion many users seem to experience is because the structure view is thought of as a track sheet. In fact it is more like a map for navigating the arrangement. 

Something like this would probably ease the learning curve for people moving from a DAW to synfire, which would be great from a support point of view. However I'd hate to loose the current workflow and fundamental design of synfire, especially after taking all this time to learn it's different but powerful workflow. Additionally Synfire would make a very expensive daw, with limited daw features, in a saturated market. I bet most of us already have a daw of choice, where we perform the final mixdown, add additional 'mastering' effects and maybe tweak the odd phrase or two before producing the wav file to prepare for distribution (or whatever).

One other problem with a big change like this, is backwards compatibility, I'd hate to loose the ability to load up music created on previous versions or have them rendered in a different way. 

Maybe the answer is to adopt this style/workflow for the cut down versions of synfire. At a lower price point, the support costs can quickly eat into the profit, so reducing those by adopting a more daw like interface might make sense.

The discussion somehow reminds me of text editors and word processors. 

Most users (like 80%) don't use structured formatting. They just type ahead and insert blank lines for spacing. If they need a heading they make it bold, increase font size and insert an empty line after (and decrease font size again). This is absolutely intuitive and works ok for short documents. 

Once you have a lot of text on multiple pages, and maybe with images and tables in between, things start getting awkward when you delete or insert additional text.

A text editor can serve both workflows without sacrificing anything. I wish this was also possible with Synfire. Start with intuitive brute force and move to structured arrangements later (if you need it). No idea yet how this could be achieved.

Currently I work on a project with ca. 15 instruments and it is not very easy to address them. 

 

Is it not possible to have 15 instrument tracks with a child container in them at certain positions , as in @juergen's example template?

Currently I have to scroll inside a small window to the right instrument and see there a lot I don't want to see.

Have you tried the "Eye" button? Unused instruments take up only a tiny space. Just large enough to make them visible again when you need them. 

Maybe that can be improved further by completely hiding them behind a drop-down menu or something? 

For me, the "Eye" and the "Zoom" button next to it are the most frequently clicked buttons. They are very convenient to clean up the view and avoid scrolling.

Currently I work on a project with ca. 15 instruments and it is not very easy to address them. 

I agree, that working with a large number of instruments can be a bit of a pain. But the problem is not the container concept, but the windows concept. 

I was never fond of this "one-window-for-everything" concept with tabs and buttons to switch the views, that was introduced sometime during Synfire 1. And it has gotten worse and worse over the years (as the number of views and features has increased). I think we wouldn't be having this discussion at all if it were possible to set up three monitors, for example, so that the container view is on one monitor, the instrument list on the second and the output view and perhaps the phrase editor on the third. Instead, we constantly have to switch tabs and then additionally we need to press some view buttons with cryptic icons with eyes, arrows, grids and whatnot, that I still have to think for a second about what they mean every time. 

Yes, I admit that I'm not a big fan of the user interface either. But instead of restricting the flexibility even further (which would in any case hinder the workflow of some users), I am in favor of making it more flexible again so that everyone can decide for themselves where and how each of the windows are displayed. And by the way: I would like to have a transport panel as separate window.

I appreciate the discussion. It is important to reflect on this to improve the user experience and nothing is better than feedback from informed users. But as you noted, every user has a different perspective.

At the moment, e.g. also confusing is, if I am in phrase editor and select a different container, it shows me the same instrument there - what is somehow not my expectation if that container is even not using that instrument.

All navigation boils down to Container => Instrument => Parameter. While it would be possible to have independent such selection states in different views (or per container), whenever possible this is a global selection state. So yes, if you switch to another container, you'll see the same instrument and parameter even if it's empty.

A global selection state is also required for drag & drop. If you drop a phrase on a container (e.g. from a library), you always know it will go the the currently selected instrument.

IMHO seeing the list of instruments on the left side and select anytime another is also good.

I like the idea of having track headers left of the big phrase editor. It could help avoid the confusion you just described, as it clearly indicates where you currently are and selecting a different instrument doesn't require a pop-up menu.

I was never fond of this "one-window-for-everything" concept with tabs and buttons to switch the views

There is no way around this all-in-one layout nowadays. Three monitors and views in separate open windows is a setup I also like very much, but we are a minority inside what is already a niche (I do indeed have three monitors, too). The majority of users is running Synfire on a Laptop.

Single-window layout also makes it easier with multiple arrangements open at the same time. Imagine the confusion if all of them had multiple windows.

Three monitors and views in separate open windows is a setup I also like very much, but we are a minority inside what is already a niche (I do indeed have three monitors, too). The majority of users is running Synfire on a Laptop.

I didn't mean that three monitors should be the minimum requirement for using Synfire :) Of course, I also want still to be able to use it on a laptop. I was only thinking about adding flexibility.

When I look at Cubase, for example: There is also the concept that the screen can be split horizontally and the tracks view can be displayed at the top and the piano roll view for example at the bottom, But I can still open each window separately and place it wherever I want. That's what I mean. Additional flexibility.

Competing with a UI framework that took 20 developers more than 20 years to make is tough, but yes. I agree there is room for improvement ;-)

As  newcomer to Synfire and one who has invested so much time into learning the software coming from 2 DAW's since 2003, I am really leaning towards what Jurgen is saying.

I dont think the containers is the true issue, for me its the layout. Having said that, that is one thing many DAW's are good at implementing. They have many mixing and editing features and they have to present it to the user in an intuitive way.

One Idea is to just seperate screen layouts for Phrase editing and Containers. Everything else has its own very detailed screen, the Matrix, Library, Snippets etc.... If we can get an entire redesigned layout for Phrase editing and Container editing that would definitely keep me from scrolling around so much. Im not sure how this would look but we'd be able to put alot more information about our current tasks in the layout in an intuitive way. Phrase editing is one of the most powerful things about synfire and should have its completely own separate Tab.

This shouldn't be to hard to implement and then we could have the ability to have each Tab or layout open on different monitors. That would supercharge the workflow without changing any features.