Posted
My friend gave me an old Mac mini. I installed Synfire and ran through all of the things I have problems with on my Windows machine. I have none of the problems with SFP on the Mac that I have on the Windows machine.
I can do all of the below on the Mac without issues:
- Open SFP files from finder without getting SFP's dialoges and missed connections - global instruments or otherwise.
- Open SFP files without the SFP engine running without getting SFP's dialoges and missed connections - global instruments or otherwise.
I do notice that if I quit the DAW project before SFP, SFP forgets the global instruments on the next start. So, it all might have to do with the save routine that happens when the user exits SFP.
Of course, I am not saying it is Windows' fault. Maybe SFP needs more testing on Windows? One other difference is that I am building the SFP project on the Mac from scratch, whereas the SFP project on Windows I use to test was built over a year ago.
Thought I would pass this along...
Sun, 2011-12-04 - 10:14 Permalink
Synfire's application-level code is identical on Windows and Mac. The problems you describe are not related to OS-specific functions. I would rather say it's something obscured inside the specific project. Maybe a reference to an engine port that does not go away or something like that.
I do notice that if I quit the DAW project before SFP, SFP forgets the global instruments on the next start.
Synfire saves the current status to disk on exit. This is to ensure that all changes are persistent. How is it supposed to know whether the user deliberately wanted to removed the rack, or whether the DAW just crashed? I will nevertheless check why it still forgets the global instrument assignments in this situation. It should not, unless the user assigned a new sound.
Rule of thumb for the shutdown procedure is:
- Save Synfire project
- Save DAW project
- Quit Synfire
- Quit DAW
Hosting global instruments in a DAW is not a good idea anyway. The whole point of a global instrument is that it is always available. It should not depend on manual setup or startup sequence.
Sun, 2011-12-04 - 13:53 Permalink
Synfire's application-level code is identical on Windows and Mac. The problems you describe are not related to OS-specific functions. I would rather say it's something obscured inside the specific project. Maybe a reference to an engine port that does not go away or something like that.
Makes sense - although maybe there is something happening with the dialogs in one OS that does not happen in the other. I will try a from-scratch project on Windows.
How is it supposed to know whether the user deliberately wanted to removed the rack, or whether the DAW just crashed?
Easy: The user says so - by saving the project manually. The user knows what is going on with their system and therefore when and whether or not changes should be comitted to SFP racks and devices!
I will nevertheless check why it still forgets the global instrument assignments in this situation. It should not, unless the user assigned a new sound.
Thanks
Hosting global instruments in a DAW is not a good idea anyway.
That's one man's opinion. :)
Sun, 2011-12-04 - 17:30 Permalink
I will try a from-scratch project on Windows.
I tried the same test on Windows. It does not work on Windows, but it does work on Mac. Hmmm.
To reproduce this, all you have to do is:
- Create a DAW project with a MIDI only drone for a global instrument and a MIDI only drone for a normal instrument.
- Hook the drones up properly.
- Un-check "Use audio engine" and "Launch audio engine on startup".
- Save the projects in the proper order.
- Re-open them in the proper order. Notice the global instrument connections are broken.
- Additionally, try setting up the test again and then opening from Windows Explorer. (Yes, I know we're not supposed to do that, but it works fine on the Mac.) Notice both global instrument connections are broken and regular instrument connections are broken.
I can reproduce this every time. If you do this test, I guarantee you see problems. And, it's only on Windows. There are other random problems and pop-up dialoges that happen when doing this; you will see what I mean. I promise.
I know I can work around this, but the reason I am focusing on it is I think fixing all of this will probably help overall connection reliability and reduce users' confusion.
Wed, 2011-12-07 - 19:26 Permalink
Just tested this now and found two things:
- On Windows, it seems the DAW drones take a few seconds longer to login with Synfire, that is, before pressing "Yes" in the "Please start DAW..." dialog, waiting three seconds (or waiting 1 sec. after the "Online" indicator in the drone got lit) does the trick. I'll try to eliminate this by making Synfire wait longer before timing out.
- The shared device I used for the MIDI-only drone did not have sufficient channels free for dynamic allocation which broke the gobal instruments. I could fix that by adding more dynamic channels. This however, has little to do with your test, though.
- I tested with the latest development build (not yet online), so my situation may already have improved compared to when you were testing.
I'll hack something to avoid the timeout and upload the current build then.
Wed, 2011-12-07 - 19:43 Permalink
That makes sense. After further Windows testing, pressing "Yes" when that dialog appears usually resolves the issues. But, the dialog often appears intermittently when it should not. Presumabely, that is due to the different amounts of time it takes to login depending on system state. Hopefully we've figured it out. :)
Looking forward to the next build...