Yes, I know that I've already written way too much. Just a few more comments on your response and then I will be quiet about this.
Overview is meant to show the final output per instrument ... it's cool for smoothing out transitions etc.
It could be cool, but at the moment, the coolness of editing in the Overview page is a bit limited by its design. It just doesn't make sense to me if you are supposed to edit in one place (the phrase editor) and check the result in the overall context in another place (the overview). Especially when the display for this review is designed like...well the German special term for this would be "Mäusekino" (cinema for mice).
Editing should take place where you can also view the result. Then you could completely dispense with the phrase editor in the overview page. This would also improve the real overview, because if all display options on the overview page are activated - the container structure, the tracks-overview and the phrase editor - then there can no longer be any talk of an "overview", at least on a normal FHD monitor.
The possibility of parameter editing in the overview tracks would also improve the functional consistency throughout the program, because then you could say that (with the exception of the output parameter, which for good reason is a read only parameter) all parameters can be edited wherever they are displayed.
Or the Overview page might be renamed "Tracks" or something.
That would make sense and it would not restrict its use as an overview display anyway.
Making the track sheet read-only would indeed be stupid (at least this thought got the discussion going).
The reason why I have such an allergic reaction when I hear that something might disappear is that we've already had this a few times. I'm still struggling with the missing cross-arrangement container transfer functionality, the "optimized" quantization options and the windows management. And in general it annoys me, when there are attempts to sell a step backwards as progress, which is modern these days.
I can see where juergen is coming from. I miss the cross-arrangement container transfer functionality and other changes, but I can also imagine the complexity of trying to deliver his vision (wishes). Selecting any note or parameter is "easy" to work out which container needs editing, enabling the correct contents to be displayed in the 'edit widget' or actually altered in place in the overview. The problem comes when a range of notes or parameter instances are selected, or to a lesser extent when a new note/figure or parameter value is added or an existing one moved earlier or later in the piece, especially when the positions span multiple containers. Creating a nested container for the 'edits/additions' that overlaps the span of affected containers, snapshoting the selected timeline might help, although would be incompatible with the mode where all containers are continuous and versions of synfire that dont support nested containers to the required depth.
Unlike juergen, I wouldn't have a problem using a fixed place "edit widget/display" in the overview that displays the selected notes/paramenters I want to change from the appropriate container. This makes sense to me when i might want to change say the transpose data, I can see/edit the transpose data in the edit widget and see how the changes affect the notes rendered in the overview.
I've only just upgraded to version 2 and haven't used it yet so please take that into account, all my comments are based on version 1 and what ive seen or read about version 2.
I have far to go before I could have an opinion about the deep details discussed here, but it does remind me of something.
In Cubase, there is a mode called Arrange Mode. It is, in a sense, an algorithm that allows specification of sequential orders, repeats etc. Using Arrange Mode you reference multi-track sections of linear material and chop/rearrange to your liking, non-destructively. You can have many alternate Arranger chains, play them back, save them, alter them, decide about them, etc. Some here may be familiar with it.
Then there is an operation called "Flatten" which takes the output result of the Arrange mode and rewrites it all as linear material (in-place on the original tracks). This is -totally destructive-. You definitely want to save your Project before you do this so you can return to it and continue to fiddle with the Arranger Chains when/if desired.
You would never Flatten until you really need to, but when you need to, you need to, because for example you have new material to record that has to lie over the entire length (or across sections) of the Arrangement.
It seems to me that this conversation revolves around some of the same issues.
If I understand correctly, by analogy, current similar workflow using Synfire would be to render out to MIDI files (i.e. flatten), and then take up further work externally in a DAW of choice.
As divisions go, that's a bright and shining line and I tend to favor those. They aid understanding. Synfire does a certain thing (Container hierarchy) which is a challenging enough to understand by itself. Then, when you want pure DAW track behavior, you go to the DAW. For better or worse in implementation and execution, this is CLEAR. The paradigms are not mixed.
Now, if Synfire were to become also literally a DAW (as commonly understood), just like other DAWs -in addition- to what it is now, then the UI goal would be, IMO, to be always PERFECTLY CLEAR when Synfire is in container mode and when it is in DAW mode. And the operational goal would be for Synfire to be BOTH a superb container-based app and a suberb DAW.
This is a tall order. And, it would make the program as a whole quite a bit more difficult to understand in its entirety.
Perhaps it is doable, but the question I would ask is: is this the best use of the huge amount of time it would take (yes?), or would the time be better spent on:
a) continuing to evolve Synfire to ever-ascending excellence in it's own paradigm, while
b) giving serious further attention as necessary to import/export/inter-operation capabilities and workflow along the way
So, I offer that as a frame for consideration, FWIW. Cheers!
Sun, 2023-11-19 - 14:47 Permalink
Yes, I know that I've already written way too much. Just a few more comments on your response and then I will be quiet about this.
It could be cool, but at the moment, the coolness of editing in the Overview page is a bit limited by its design. It just doesn't make sense to me if you are supposed to edit in one place (the phrase editor) and check the result in the overall context in another place (the overview). Especially when the display for this review is designed like...well the German special term for this would be "Mäusekino" (cinema for mice).
Editing should take place where you can also view the result. Then you could completely dispense with the phrase editor in the overview page. This would also improve the real overview, because if all display options on the overview page are activated - the container structure, the tracks-overview and the phrase editor - then there can no longer be any talk of an "overview", at least on a normal FHD monitor.
The possibility of parameter editing in the overview tracks would also improve the functional consistency throughout the program, because then you could say that (with the exception of the output parameter, which for good reason is a read only parameter) all parameters can be edited wherever they are displayed.
That would make sense and it would not restrict its use as an overview display anyway.
The reason why I have such an allergic reaction when I hear that something might disappear is that we've already had this a few times. I'm still struggling with the missing cross-arrangement container transfer functionality, the "optimized" quantization options and the windows management. And in general it annoys me, when there are attempts to sell a step backwards as progress, which is modern these days.
Sun, 2023-11-19 - 18:13 Permalink
I can see where juergen is coming from. I miss the cross-arrangement container transfer functionality and other changes, but I can also imagine the complexity of trying to deliver his vision (wishes). Selecting any note or parameter is "easy" to work out which container needs editing, enabling the correct contents to be displayed in the 'edit widget' or actually altered in place in the overview. The problem comes when a range of notes or parameter instances are selected, or to a lesser extent when a new note/figure or parameter value is added or an existing one moved earlier or later in the piece, especially when the positions span multiple containers. Creating a nested container for the 'edits/additions' that overlaps the span of affected containers, snapshoting the selected timeline might help, although would be incompatible with the mode where all containers are continuous and versions of synfire that dont support nested containers to the required depth.
Unlike juergen, I wouldn't have a problem using a fixed place "edit widget/display" in the overview that displays the selected notes/paramenters I want to change from the appropriate container. This makes sense to me when i might want to change say the transpose data, I can see/edit the transpose data in the edit widget and see how the changes affect the notes rendered in the overview.
I've only just upgraded to version 2 and haven't used it yet so please take that into account, all my comments are based on version 1 and what ive seen or read about version 2.
Wed, 2023-11-29 - 22:33 Permalink
Hi
I have far to go before I could have an opinion about the deep details discussed here, but it does remind me of something.
In Cubase, there is a mode called Arrange Mode. It is, in a sense, an algorithm that allows specification of sequential orders, repeats etc. Using Arrange Mode you reference multi-track sections of linear material and chop/rearrange to your liking, non-destructively. You can have many alternate Arranger chains, play them back, save them, alter them, decide about them, etc. Some here may be familiar with it.
Then there is an operation called "Flatten" which takes the output result of the Arrange mode and rewrites it all as linear material (in-place on the original tracks). This is -totally destructive-. You definitely want to save your Project before you do this so you can return to it and continue to fiddle with the Arranger Chains when/if desired.
You would never Flatten until you really need to, but when you need to, you need to, because for example you have new material to record that has to lie over the entire length (or across sections) of the Arrangement.
It seems to me that this conversation revolves around some of the same issues.
If I understand correctly, by analogy, current similar workflow using Synfire would be to render out to MIDI files (i.e. flatten), and then take up further work externally in a DAW of choice.
As divisions go, that's a bright and shining line and I tend to favor those. They aid understanding. Synfire does a certain thing (Container hierarchy) which is a challenging enough to understand by itself. Then, when you want pure DAW track behavior, you go to the DAW. For better or worse in implementation and execution, this is CLEAR. The paradigms are not mixed.
Now, if Synfire were to become also literally a DAW (as commonly understood), just like other DAWs -in addition- to what it is now, then the UI goal would be, IMO, to be always PERFECTLY CLEAR when Synfire is in container mode and when it is in DAW mode. And the operational goal would be for Synfire to be BOTH a superb container-based app and a suberb DAW.
This is a tall order. And, it would make the program as a whole quite a bit more difficult to understand in its entirety.
Perhaps it is doable, but the question I would ask is: is this the best use of the huge amount of time it would take (yes?), or would the time be better spent on:
a) continuing to evolve Synfire to ever-ascending excellence in it's own paradigm, while
b) giving serious further attention as necessary to import/export/inter-operation capabilities and workflow along the way
So, I offer that as a frame for consideration, FWIW. Cheers!