Posted
I am sure I'll be happy with the drone system once the bugs are fixed. Looks like progress is being made.
However, for me, Synfire as it exists now is in sidekick-to-the-DAW status. That is not a bad thing, because it will make a very powerful sidekick, but there are a couple of obstacles that prevent it from rising to the status of being the primary composition environment envisioned.
I mention these because they haven't changed in the three years since the beta was first released.
1. Creating figures is difficult - manipulating existing figures is fairly easy and comfortable, but creating new ones from scratch, not so much
2. Drums are very difficult (due to item #1). Best left to the DAW.
3. Using more than one independent instance of an instrument is difficult.
Thankfully, the drone system will provide a great deal of relief in some of these problems, in that they can now be handled in the DAW. So I am excited to dust off Synfire and get to work on some serious projects, albeit primarily in the DAW with Synfire supporting it.
Now, I would like Andre to see his vision of "Synfire + Huge Rack in Audio Engine = All You Need" come true. But for me, that won't happen until the three non-trivial concerns above are mitigated.
(I did make a post a couple of years ago that contain some detailed suggestions that might help with item #1. Maybe after all the bugs are fixed in 1.5, you could take another look?)
Let me know what I can do to help...
Tue, 2011-11-29 - 22:45 Permalink
Thanks for the input. I much appreciate it.
I can not agree more with your point that creating figures from scratch is a challenge. This is partly due to the known weaknesses of the current edit tools, partly because figures are very different from a piano roll, so long trained habits are almost useless here. And, to be honest, more often than not it's just the "blank page" effect. It's always difficult to start without anything to expand on. That's why I always encourage copy & paste.
My favorite way to get a figure into Synfire is to record it (multiple voices and sections in overdub mode) and then refine the resulting figure manually. But I acknowledge that this method might not suit everyone. Even though pitch is not so important at this stage, it largely depends on your rhythmic skills on the keyboard.
I'm glad your list is as it is, because the issues will be addressed anyway, once the drone bugfixing is complete. I am also dissatisfied with the figure editor in its current incarnation. The list of items on our agenda is long and they will be addressed in the general user interface overhaul that comes next.
Here are a couple findings that will be considered too:
The line drawing tool is pretty useless. While the results looks nice, they often do not make much sense musically. Music works sequential/incremental, rather than spatial/geometrical. Years ago someone suggested an ability to draw a circle -- well, that would even look nicer, but be even more useless musically. The solution most likely is to generate incremental patterns from sketched lines, i.e. a move straight upwards the scale, only roughly followig the sketched line.
Switching tools is annoying. It should not be required at all! I played around with different vector drawing software and noted how object selection - even with nested structures - can be implemented more intuitively. Improving this will be a huge step forward.
Multiple selection is only partially implemented. This will also change.
After spending almost a year on audio development, there is sufficient distance and objectivity now concerning these tools. This is a very good precondition for successfully improving things.
Tue, 2011-11-29 - 23:12 Permalink
hey
when you talking about the editor then something like this is, what I would like to see in SFP
Wed, 2011-11-30 - 00:22 Permalink
Awesome!
By the way, here is the post I was talking about (from December 2009):
(https://users.cognitone.com/content/selectionclipboard-behavior-phrase-…)
Thu, 2011-12-01 - 04:34 Permalink
Sure thing.
In short, instruments are tightly coupled with devices*, and this can get in the way.
A couple of years ago, I remember trying to have two or three of the same instrument. It was one instance of the same device for all three; in other words, all three Synfire instruments ultimately sent their output to the same MIDI port and channel. I just wanted three independent layers in Synfire, but Synfire seemed to identify the instrument by its device, and behaved in such a way. For instance, when I muted or soloed one, the others would do the same. Not what I wanted!
The coupling of instrument and device forced me do routing workarounds on my rack so Synfire would think they were all independent.
Nowadays, with the new Synfire shared rack, the device description represents an instance of the instrument, instead of a class as it should. A common use case for me is to use two or more instances of a the same plugin in a project, each with different patches or presets. But this won't work, from the way I currently understand it. So, in order to do this, I need to make copies of the device description.
So this basically means I'll be skipping the Audio Engine entirely, and opting for the drones. Here's why:
1. My device description list is already getting too big. I don't want it to add NxM more descriptions, much less very verbose ones, that appear in a listbox that is not sizeable and I won't be able to read them anyway.
2. If the main device description changes in any way, I need to make new copies.
3. The left side of my brain refuses to let me do it this way.
I might decide to use the Monster Synfire Rack method (and believe me, I agree it would be awesome!) if this problem is addressed. But right now it is a major wall. It might sound like it'd add some complexity to add another layer to represent instances of a class of a device, but it'd remove the wall.
* (In fact, instruments also are tightly coupled with players and parts, which leads to another wall when it comes to orchestration, but this is separate suggestion)
Mon, 2011-12-12 - 20:58 Permalink
Ok, the listbox should not only be resizable, it should also be tabbed (Devices, Templates, Private Devices, etc).
A common use case for me is to use two or more instances of a the same plugin in a project, each with different patches or presets.
Each preset would require its own description, at least for a sample library that has fixed midi channels 1-16 assigned. A device class "Kontakt 5" would not make sense, as there are thousands of possible presets/sample libs Kontakt 5 can load. And these usually do not have much in common concerning patch names, CCs, articulations and such.
A typical "device class" would rather be a synthesizer-type of plugin that uses the same list of factory presets on all instances.
It might sound like it'd add some complexity to add another layer to represent instances of a class of a device, but it'd remove the wall.
Agreed. I could think of just making an Alias of a device if it is supposed to be used multiple times. This would save the extra layer for most cases (devices are instances by default).
For instance, when I muted or soloed one, the others would do the same. Not what I wanted!
This is working now. Instruments with the same fixed midi channel assignments (or those that you grouped together deliberately) can now be distinguished by the drones and the engine. You can mute/solo them independently.
Mon, 2011-12-12 - 21:43 Permalink
I could think of just making an Alias of a device if it is supposed to be used multiple times. This would save the extra layer for most cases (devices are instances by default).
Yeah, that would be great. Especially for plugins like Omnisphere which have thousands of presets.
Sounds like a good idea to me.
This is working now. Instruments with the same fixed midi channel assignments (or those that you grouped together deliberately) can now be distinguished by the drones and the engine.
Thanks for fixing this! You've been pretty responsive to a lot of my concerns as of late. I appreciate it.
Tue, 2011-12-13 - 14:28 Permalink
....The list of items on our agenda is long and they will be addressed in the general user interface overhaul that comes next....
....The solution most likely is to generate incremental patterns from sketched lines, i.e. a move straight upwards the scale, only roughly followig the sketched line....
....After spending almost a year on audio development, there is sufficient distance and objectivity now concerning these tools. This is a very good precondition for successfully improving things....
Andre
Would it be correct to understand that when the current audio implementation has been finalised, a more refined user interface and method of entering musical information will be addressed?
Could you please elaborate further on the new tool ideas?
Tue, 2011-12-13 - 16:49 Permalink
@sprekht: Yes. However it is a bit early to commit to a particular roadmap yet. Before we start adding new tools, we need to improve all pending things related to the window layout, the phrase editor, keyboard shortcuts, etc. When the current foundation of tools is comfortably accessible, we will start with new tools.