Posted
For quite some while now I am scratching my head over a fundamental design question and did not come to a conclusion yet. So I thought: Why not ask the community about this?
The question is whether the engine should be closely tied to Synfire, or not. Should Synfire launch it on start and kill it on exit (as it is now)? The engine has been desigend to work independently. It can even save its racks to disk. So why not just keep it running until the user quits it from the system tray menu (or dock). This would save the wait for loading plugins. The only downside I could think of is that, as an engine is almost invisible, it may keep sitting in the background, eating up memory and CPU resources while the user forgets about it.
How would that suit your workflows? Do you frequently quit and restart Synfire (e.g. by double-clicking a project in the Windows Explorer), or would you prefer to keep it open all the time? On the Mac, closing the last window does not quit Synfire, so it is much less likely that one accidentally exits the program. On Windows it may happen quite often.
I could make this a preference setting ("Keep Engines Running on Quit"), but are interested in your opinions as to how useful that would be.
Mon, 2011-10-24 - 13:18 Permalink
I usually expect to have a clean system after a programm exit rather than to have hanging around some "ghost engines" in the background. So, if I did not know this discussion I certainly would think that this behaviour is a bug. Having an option "Keep Engines Running on Quit" is a good thing but should not be the preferential setting.
It's right that it can happen to exit the programm accidentally on closing the last window. But after a while one gets used to this behaviour so I don't think that this is a big issue.
Mon, 2011-10-24 - 23:35 Permalink
Thanks for your feedback. I made it an option that defaults to off.
On a side note, if a project is hosted in a DAW, that host also keeps running after Synfire is quit. When Synfire restarts, it recognizes the original drones in that DAW and knows to which Synfire project they belong. The ports show up with a comment
"The project "XYZ" belonging to this port is not currently open."
Then you probably go and open that Synfire project and --- ta ta ta! --- the ports go back home where they belong, i.e. they reconnect to the project's instruments.
It does not work so convenient the other way round. If you attempt to open a DAW-hosted Synfire project without previously starting the DAW with exactly that project loaded, Synfire complains that it can not find the original ports. You have to decide either to start the DAW or choose a replacement, probably an engine, as a target for the saved instruments.
This is really cool and flexible, although it's still full of bugs currently. I'm fixing these right now.
Tue, 2011-10-25 - 00:31 Permalink
If you attempt to open a DAW-hosted Synfire project without previously starting the DAW with exactly that project loaded, Synfire complains that it can not find the original ports. You have to decide either to start the DAW or choose a replacement, probably an engine, as a target for the saved instruments.
If the engines are not running, I get this message when opening a DAW-hosted Synfire project even with the DAW open and the correct project loaded.
Tue, 2011-10-25 - 01:06 Permalink
I know. That's the bug I just found and fixed a minute ago ;-)
Duplicating drones in the DAW (copy/paste) caused the same IDs to occur multiple times. No wonder this messed up the references. Now it is ensured that a drone gets a unique id regardless of whatever the DAW chooses to do. I will upload a new build tomorrow.