Section vs. Container

Section seems to be perfectly fine :-)

As far as I remember, Harmony Navigator already used "Section" as structuring element long time ago.

Have a nice easter weekend :-)

Yes ... words matter a lot.

I'm not convinced that "Sections" captures the flexibility Synfire offers in "Containers".

"Section" has a well-established meaning in music that includes context.  Structure is common but notions of Inheritance and Priority by individual parameter are missing.  These are fundamental elements of the Synfire difference.

Some might find "Sections" and "Child Sections" confusing.  I agree that "Folders" doesn't do justice either.

An alternative doesn't readily spring to mind.

See https://en.wikipedia.org/wiki/Section_(music) and https://grokipedia.com/page/Section_(music) for the landscape.

I'm keen to see what surprises await!

I agree with Raymond, section is for me AABA as in a song.

Here's an Easter surprise: Block :-).. as you use earlier in LEGO
Or maybe:  consection ?
Or just        partblocks  : 
Or just:   sectionblocks 
Or just   sectionpart 
Or just   sectioncontainer 
Or just   containerblock
Or just  containersection
Or just  containerpart => no reference to a musical section, stands on its own 
Or just partcontainer ..maybe better 

Its not easy and  a block is not really  a attractive name  
Maybe then : Patternblock
                         Patternsection

section is for me AABA as in a song

That's exactly what most users use it for

I don't know ...

Container is the appropriate software term for what is actually implemented in Synfire.  To understand and use SF well, the user has to understand the container concept accurately and deeply, IMO.

I think you could easily wind up with alot of explaining to do about how Sections are not really sections as normally understood, but are actually containers, with very specific "container-like" behavior that differs from how "sections" (as in DAWs, or just in general) may be commonly understood (or assumed about).

If this was being determined from scratch, the nomenclature might be worth worrying or arguing over, but as 

(user interface, documentation) and some videos will have to be redone

I find it kind of hard to see the upside of the change.   (Whereas that downside seems quite significant.)

IOW, it may be alot of work for not much forward motion (possibly even backwards motion, by making the truth more obscure).

What is the real driving need/motivation here?

And, do you need reminders or ideas of real enhancements and extensions remaining to be done? <g>

I doubt that changes like these would cause sales figures to skyrocket. If there are any issues in this regard, I can think of other reasons for them.

As for the term "container". To me, the current term makes perfect sense. It describes exactly what it is. The musical term "section" is something else (as already mentioned above). If it really needs a different name, in my opinion "Clip" would have been a good (i.e. second best) choice. But now that the phrases have turned into "Clips", that’s obviously out of the question. Actually, that change was another topic I had to hold back from commenting on.

By the way, FL Studio has the term “Pattern,” and it’s pretty much the same thing as a container in Synfire. That means a pattern can contain just about anything: MIDI data from one or more instruments, automation data, audio data, and any combination of these. So for someone coming from that background, this term would be pretty self-explanatory. But honestly, I'd keep the current name.

I'm not sure trying to mimic the terminology used in linear composing is the right way to go as it just confuses people when they find out it doesn't work the same as they expect. That will result in negative feedback, you only have to see the feedback over the years of those that expect it to work like a daw. Better documentation and video tutorials seem a better way to lessen the learning curve without weakening the message that synfire is a better workflow/tool for composing than linear editing.
That being said, I'd love the addition of a section type, but would prefer this to represent a named segment(span) in time showing the resulting output. It would be great if you could create a section from a time span and it get it's contents from the hieratical container structure, figures/clips and parameters contained in that time frame. If you could add the option to create a section and if the span is empty, add a container, maybe people used to sections could use that as an entry into containers. Of course if someone adds another child container to the section, then the section data would show the result. Sections wouldn't be able to overlap and could be shown above the containers.
Keep containers, saves having to redo all the documentation, third party tutorials and videos, you just need to do a new set of docs and videos about using sections to manage/view (nested) containers.

Containers would work as they do now, they can span section boundaries, sections are linked to the output view. However anyone new to synfire could just create a section and have it automatically create a container so they can edit it as they see fit. Once they get to container idea they can start adding nested containers, parameter containers and lastly containers that span section boundaries. 

Increased adoption (more users) 

About this, a few more comments, suggestions, FWIW  -   ( I will write with a direct style, but please know that I respect and honor your own knowledge and experience, which surpasses my own)

Price is a thing, a real thing.  The single most likely path to more users is likely a significantly lower price.   Make the entry level free, or truly trivial in price.  Let people stumble with the concepts at no (or very low) cost.  Then make the next two levels much less expensive than they are now.   How much less?   How many users do you want ?  (to be supporting)   How many new users do you want to onboard at once?

You want a very clear path to gaining basic competency with Synfire.  Link it with marketing.  Something like "Master these 12 tutorials and make music like never before possible!".   If the new user can accomplish this much with the free (or least expensive) version, so much the better.

Weed out the obsolete tutorials.   Redo them, or disappear them, or at least hide them deeper in an obsolete/historical/legacy area.    It makes learning much harder if the learning materials don't match the actual program exactly, visually and functionally.

If the creation of docs and tutorials is inefficient in any way, SOLVE THAT.   Goal:  being able to create a good tutorial on any aspect in no more than a single day.

Have sales.  Everyone in the world has sales.  People are totally conditioned - if it is not on sale, I'm not even looking at it until it is.   Believe me, I personally agree and sympathize with "one price for everyone, always, and well worth it!" , however the mass marketplace is what it is and whatever upsides swimming against the tide has, maximizing users is not one of them.

You mentioned in another topic about historical reasons that have limited the libraries shipped with SF.  You also hinted that this might be changing.   YES.   This would be a very high value improvement.  Have at least one KILLER library in the product for every genre of producer you want to attract, and have at least one video (preferably more) showing it off!

Demo projects have been historically under-used.   All seasoned SF users know that one really well realized project paves the way to more.  SF should have a couple fist-fulls of really slammin' demo projects.   Each of these should have available  both a video and a file.   The quality here should be as world-class as you can make it.   If you can feature artists as part of doing this, then so much the better.

Artists can be interviewed as well.

Also, a deep as-long-as-necessary tutorial on starting from one completed project and morphing it into a completely different project would be a good one, IMO.

For tutorial info, do your best to address both "watchers" and "readers".  People have different learning styles, or may learn best when reinforced both ways.  So, white papers and web pages, as well as videos.

Organize around:  Library/Tutorial/Marketing/Sale.      Make it efficient.   A new Library/Tutorial/Marketing/Sale every other month would be a great goal.   But if you can't do this at least every quarter, you must fix that.

The other important vector, after or alongside of targeting musical genres, is to target current users of DAWs.  Make Q1 "Bitwig quarter", make Q2 "Cubase quarter".  etc.   This should not be merely marketing.  Before each push, solict and act on feedback from those in your current  user base already well familiar with that DAW.  Learn from them what every point of friction is, fix those points of friction to create an efficient, fun, smooth interoperative experience,  and then target-market to users of that DAW with info, tutorials, testimonials, and sales.

BTW, if you are willing to say, Cognitone is how many people?

I'm writing as if there is at least a small team available.  If it's just one person, well, carry on, you are already accomplishing miracles!

Best wishes for (no) more users (than you can deal with)!

Oh, and keep the program moving forward too, eh?   ;^)

Another tutorial idea  -  A good deep-dive comparing and contrasting linear DAW-style capability with SF container-style capability.  And after comparing and contrasting, how to get the best of both by using SF and DAWs together.

The only name what might be interesting is : patternblock or patterncontainer 

Returning to the thread I saw I wasn't alone in thinking of suggestions, with many of my own thoughts in common with others.  Unsurprisingly, Andre was concerned to attract more users.

@jurgen opened the door by suggesting other reasons.
@blacksun spoke to improved documentation and tutorials and mentioned starting with the basics of containers as sections as the foundation for more advanced uses.
@sj1 suggested 'needs' for users: a very clear path to gaining basic competency; some serious housekeeping on the current jumble (my word) of tutorials, blogs, resources, solutions etc; a return to demo projects; and more.

I'd like to suggest a plan that hopefully is not a stretch for the limited resources and could provide some timely improvements. Here we go:

* Confront the DAW issue head on by making a video that should be understood by all levels of users ... a 12 bar blues project that is as simple as possible (containers as sections).  Make the project file available. Follow it with other videos that gradually introduce features to embellish the basic project and eventually totally change the finished product.
* Consider video shorts for processes, setup etc.
* Include summary pages of key points at end of videos (reinforce the learning).
* Tidy up the jumble (move to legacy section as new content emerges).
* Add basic genre template libraries as resources allow.
* Allow Pro users to open Express and Sparks versions from the startup page (as available with Cubase Pro/Artist/Elements via keystrokes on start) - the app is so powerful the number of options/complexity are overwhelming.
* Allow the included online manual panel to float and be resized.
* Start a Workflow section in the forum. 
* Explain the differences between Clips/Phrases/Parts/Snippets (use text, block diagrams and tables - video?).
* Run a survey of users to inform help/documentation/support priorities

It's often easier to edit a plan than start from scratch.

I also think you can enable comments on YouTube to help engagement. :-)

"I also think you can enable comments on YouTube to help engagement. :-)"
That is good idea and i don't understand why it is disabled , because it is a educational  thing