My list of suggestions

Posted Di., 15.02.2022 - 15:01

This is the thread about features.

Updated for version 2.0.10 Build #17

Marked in yellow the things that are most needed.

Exporting

Without good support for exporting and for notation, a program cannot be considered music prototyping / composing aid software.

Basic notation support (accents, etc.)

Dedicated thread: (https://users.cognitone.com/topic/basic-notation-features-add-xml-eleme…)

Option to disable MIDI pos and length manipulations when exporting

An option in the global export settings to disable Shift, Pause, Flow and Step parameters for the entire arrangement when exporting. This way, if the user wants to export to notation (or to MIDI and then to notation), things like rubato will not affect the output.

Highlight tuplets

(this feature depends on tuplets support which is yet to be completed)

Automatically recognize tuplets and highlight them in some graphical way, e.g. by highlighting the affected symbols or by writing "3", "5", etc., inside those symbols, so that the user knows when his measure contains tuplets; this will immensely help if you want to export to notation, but even if you don't, because it helps to better visualize tuplets in the "piano-roll".

Export velocity to XML

Exporting to XML has some advantages over MIDI (especially if accents & co. will get implemented), however most programs read velocity from XML too, so it would be ideal to export this parameter too.

Voices support

So that we don't need to create two instruments for e.g. piano right-hand voice 1 and piano right-hand voice 2, and so that it's easier to see the proximity of voices.

This will then be a good starting point for more advanced long term features like meaningfully managing the conflicts among the voices.

General usability, workflow, GUI

"Split to track below" and/or "Split to first empty track"

Currently, we have to delete the resulting unneeded instrument each time... Depending on what (and how many things) you have to do, this can be pure pain.

Custom colors for musical keys

Probably the only one everyone agrees on is the yellow C Major. But everything else is individual, so the user should be allowed to pick his own colors. To some people, seeing the keys in a "wrong color" can be quite annoying.

Custom colors for symbols

Similar to the former feature; maybe less important, but when you're thinking music in your head... you may visualize the sound of piano bass notes in a certain color, which is certainly not pink... ;)
If you let the user specify the hue only, there should be no issues with displaying the custom colors. In any case this would obviously be an optional feature.

Select symbols of given color only for selection

If a group of symbols is selected, using the feature "Select Symbols For X" should apply only to the selected group of symbols. If you use the "Pointer" cursor, the selection can certainly be expanded to include the whole segment(s), but not to select the entire figure.

Resizing tracks vertically

Helpers and limiters

On the left of the instrument, depending on the selected parameter, there could be some help markings with values, so you know what you're drawing. For dynamics, there could be pp/mf/etc. (just approximate of course, for reference; bonus feature, configurable by the user).
Moreover, for things like Tempo, when creating rallentando and accelerando, you may want to know what is your current default tempo, and for that is very useful to have an horizontal line showing that, so that you can go back to your default value with ease, maybe even with a snap feature when you're very close to that line.

Rubato and Humanization parameters

Similar to the Dynamics parameter, which implementation I've appreciated very much and I'm using it a lot, any small and temporary tempo fluctuation should be separated from Shift and from Tempo; the same applies to the humanization of notes, be it position-displacements or velocities-randomization. Basically, playback-only parameters should be separated from the others.

Containers: Right clicking

Right clicking a container, before showing the menu, should select the container under the mouse.

But I understand that the current behavior may be a pondered choice.

Library minor improvement (drag & drop)

There's no reason to prevent drag & drop from the phrase preview at the bottom:

Piano music

Interpretation: Half-pedaling

Giving the Interpretation parameter the ability to generate automatic sustain pedal content is very smart and appreciated. However, with some piano VSTs the full pedal can quickly create a very muddled sound, so I suggest letting the user specify a max value for pedaling instead of always 127:

Attachments

helpers_and_limiters.jpg

interpretation_half_pedaling.jpg

library_drag_and_drop.jpg

Di., 15.02.2022 - 18:26 Permalink

That is a lot of changes for the rest of us to get used to, some of them would really improve workflows but others already have solutions. I havent used synfire for a little while so some of the following may have changed or been misremembered, just a few thoughts and things you may have missed, not trying to belittle the work you've done:

Dynamic Editing
There are different ways of selecting notes and applying changes, it is already possible to split different symboled figures into separate instruments so you can treat them differently then combine them back afterwards. I think this is covered in some of the tutorial videos together with options for changing velocities. However your suggestion would definately improve things.

Apply templates only to the selected range
If i want to do what you are suggesting, currently the best way is to create a sub-container with the parameters you want to affect, sized and posititioned to cover the range you want. This has the advantage that you can easily move it around and see the impact of it being used with different notes and different places in the music, it also means it is non-destructive to the orginal figures/notes.

Mostly there arent global parameters, most apply to a container although that container could be the main one and unless changed in a sub-container, will apply for the whole tune.

Container Resize to content doesnt really make any sense? Resize to the length of a figure in the selected instrument, the longest figure in the container, what if a figure repeats for the length of a container, resize to the length of the longest parameter which may repeat? You can drag containers to length, move them around or enter the length in the container parameters. You may be asking for this due to the way you are working with synfire based on traditional music software. Containers dictate the length of the song/section/part. I tend to have containers for into, outro, verse, bridge, chorus, etc and often those containers will have sub containers to alter those sections over time.

Libraries
I hate the new suggestion, I have libraries with lots of figures and other paremeters in them, whilst i can see an advantage of being able to see them, i'd only use the first few as the rest would only be visible with scrolling. You can rename the snipits they dont have to be called E0 e1, etc.This should give you an idea what the section is about.

Default project
This one is a bit vague in my memory, I thought there was a default project which opens whenever you open synfire so you can think of this as a kind of master template a bit like the audio and midi settings and this can be overwritten. I must admit i might be getting confused with ableton live. If I have got it confused with ableton, I would prefer this as the way of working, after all the recently opened projects are available in one of the the File menu options. In terms of project handling, although it might be a pain to always end up with an unused empty default project, I often have more than one project open and copy stuff between them, if a file open closed the previous project, there would have to be a new option to open a project without closing the currently opened one.

Tempo parameter
This is a container value, if you want to return to the previous value, create a sub container, sized and positioned for the new tempo parameter, when that subcontainer ends, the tempo will return to the previous value, no need to remember it or reset it.

Position of shift
This is to do with the timing of notes in a figure and to my mind fits with length, rhythm, step etc. under rhythm.

Packing containers
I thought this was a form of container usage where there are no gaps between containers, and it was snapshotting that copied parameters to sub containers? I tend not to use packed containers as i make heavy use of sub containers, container aliases, etc. but do use shapshotting a lot.

blacksun

Di., 15.02.2022 - 18:28 Permalink

Just like to add, I do not work for synfire/cognitone, I've been using synfire for a fair while now though. It did take me ages to get my head around the different way of working as I came from a DAW background with a linear view of music.

scriabiner

Di., 15.02.2022 - 20:01 Permalink

Thank you for the reply. I'm new to the software so, yes, certain things may just have a different workflow solution. I'll constantly adjust the first post basing on the replies that I receive.

That is a lot of changes for the rest of us to get used to

Yes, maybe those that completely changes the structure of the program are not a good thing for this reason.

Dynamics editing

"Just split"

Yes, I know about splitting. As you acknowledged, it's not ideal, it's a lot of steps compared to the proposed solution.

Apply templates only to the selected range

Just use containers

You do have a good point. It's just a different workflow, basically, you're right.

Slot for global parameters

Mostly there arent global parameters, most apply to a container

Sure; I think the manual itself call them "global", it's only in the sense that they are not tied to a slot but they apply to the whole container. I just hate not being able to see the Tempo and the Sustain while editing a Figure, that's the reason why I've proposed that feature.

Container resize

You may be asking for this due to the way you are working with synfire based on traditional music software.

Kinda. The situation is the following. You have just one instrument, so no orchestra or things like that. For organization and for easier future modifications, you divice everything in part (exactly as you were suggesting, intro, etc.); however, everytime I add content to a part, I have to manually change the container size. Sometimes you add content, but the main container is shorter, so content is truncated. Instead of manually having to resize it (which requires changing the quantization selector, etc.) you could just click that button. And I proposed a button exactly because this shouldn't be a default behaviour. But it's a useful shortcut. To answer your question, it would be the longest figure with no repeats.

Libraries

Fair enough.

Default project

if a file open closed the previous project, there would have to be a new option to open a project without closing the currently opened one.

That is not the problem, I actually like the approach of having multiple windows containing different stuff. I was just advocating for more options about what happens when you first start the program. It's more choices, not limitations.

Tempo parameter

This is a container value, if you want to return to the previous value, create a sub container, sized and positioned for the new tempo parameter, when that subcontainer ends, the tempo will return to the previous value, no need to remember it or reset it.

Very good point. So the only problem that remains is the notation. Meaning in XML you end up with tons of useless tempo changes. I guess I'll change the request in to give the option of not exporting tempo changes in the XML, that would solve the entire issue.

Packing containers

I thought this was a form of container usage where there are no gaps between containers

Nope:

With Container >> Pack, you can move all phrases of a container into a new subcontainer. The original container will be empty after this. This is very helpful if, for example, you started an arrangement in the root container and after a while want to add more containers to it. This way you get all contents of the root container quickly moved into a subcontainer.

This sounds like "extracting" to me.