Within Synfires Output parameters, the resulting different pitches are shown (and this is also preserved in the MIDI output). However, the pitches in the MusicXML are all constant, and a different pitch than shown in the Synfire Output (and MIDI export).
These kind of things are just scary. But since they cannot do unit testing because of the chosen programming language, we're always going to get critical bugs.
MIDI export inserts a bar-long rest at the beginning
That's the MIDI file standard (at least for arrangements). It may make sense to skip this when exporting only a single instrument or container, but for an entire arrangement this is needed for program changes, controller resets and similar stuff to settle. Also, there's often a count-in, pickup notes, or similar.
Suggestion: You can compensate for that offset in Synfire on the Sync tab, so counting starts on bar 2 for example. No composition should start at physical bar zero. Even more so when you are synchronizing with a DAW. As we are at it, I'll check if that is properly translated to MIDI file export.
@scriabiner: Please, unfounded speculation about engineering details and future bugs doesn't help anyone. Some things are a challenge, others are a boon without which Synfire would have never seen the light of day. What may look straightforward and simple from the outside, took many years of navigating uncharted territory, experimentation, long-term foresight, failure and frustration to get here. And we will not stop there, ok. Comments that can come across as "They don't get it, they're incompetent, it's hopless" only undermine the operation that is supposed to improve the product.
I've had a very bad day, so sorry if that was a bit harsh. No offense intended. Let's get back to topic.
Much of the unpredictability is due to Smalltalk, which has no type checking at compile time. The only way to find a mistake is to stumble upon it at runtime (it has many advantages, but this is its biggest disadvantage). (https://users.cognitone.com/comment/19709#comment-19709)
> Smalltalk ... has no type checking at compile time
Don't want to be pedantic, but this has absolutely nothing to do with the ability have unit tests as you seemingly suggested. For example, Python -- arguably currently the most popular language -- has the same deficit, and still has a whole collection of unit test libraries available. Sorry, don't want to futher fan the flames here, quite on the contrary... Apologies if this was in any way offensive.
We do have lots of unit tests for data structures and foundational classes. More complex tasks like XML export are hard to test systematically, unless you have lots of human resources to throw at it.
The issues caused by lack of strong typing are easy to fix. It's not fatal or disastrous in any way, it's just an extra hoop to jump through. On the other hand we are able to codewhile the program is running: Edit rendering code while music is playing, or edit UI code while the windows are open. What takes weeks in C++ can be accomplished in mere hours with Smalltalk.
Thanks for taking the time to check. Attached is a 2 bar example demonstrating the problem (Synfire project and resulting MusicXML file, the latter wrapped in a zip file so it can be uploaded).
For completeness and a quick check, there are some related screen shots too.
Hi, I'm still wondering if there is or might be an option to define own plugin paths on the Mac version of Synfire 2.0.11.
My Issue.... I almost can't use Synfire anymore because when I launch it and need the Audio Engine it is ALWAYS scanning my PlugIns, and I got a bunch .. I have to wait almost 25 minutes until the scanning is completed. And when I close Synfire and relaunch it.. same happens again.
So, it would be cool to define alternative PlugIn paths where I only put in those PlugIns I need for Synfire or even better there is already a solution I overlooked.
Or an option, that I can define if Synfire re-scan my PlugIns or not and remembers the last scan and ignoring changes for new PlugIns.
I am using Windows and don't know if on Mac it is the same, but I can define the folders and I think it caches the found plugin as it takes only long time once.
awesome :) somehow I was scared to click that button because I always thought it will start the scan process :)
ok, I deselected some VST Paths and ticked off the re-scan, but it still re-scans my AU plugins which I couldn't find an option to tick them off :(
edit: after 30 minutes of waiting that the AU scan finished it started with the VST scan again .. to be honest ..it's frustrating .. it ignores my settings .. why the engine is scanning when I ticked all off?
Hmm. I agree to you, it sounds like wrong behavior.
By the way, I also had to search for that setting and assumed it to be in a kind of "vst settings or path section". That 2 kind of preferences areas was always confusing to me. And yes the name also indicated to me that the scan will start immediately and I did not want to start a scan as it needs for me also 10-20 minutes. A different title would help to avoid that misunderstanding.
Hi, I have the same problem but having done the scan process on the preferences tab the loading time is very quick, I think there is another post about this!
Well after now 1 Hour :( I finally had the chance to go back to the settings. What I noticed, it reverts all changes, it doesn't matter what I delete or uncheck. When I close the preference window and go back, all is ticked on again and all the PlugIn Paths which I deleted or changed are back :(
Also, I deleted ScannedPlugins64.xml which I found in another forum post, didn't help .. starts immediately the AU scan again.
Ok, I deleted the preference file and I deleted the cognitone folder in the user library folder, and it so far did rebuild the folder and the preference file, so I have to wait another hour again to check ;)
I greatly appreciate your support AndreasHe, thank you :)
@tanders: If you look in the XML file, you see C and D exported correctly. Why MuseScore renders them as the same pitch, I have no idea. Probably intended for percussion.
Hm, strange. I can see the pitches C and D in the XML file. However, perhaps something concerning these pitches is wrong in the exported format? I just tried opening this file in Dorico, and it also cannot read these pitches and instead displays constant pitches. See attached screen shot.
I found a workaround, though it is not pretty. When I open this MusicXML file in Finale (venerable version 2012) then the pitches are displayed correctly. If I now export this Finale file into MusicXML version 2 (does also work with version 1, but not with version 3), and finally open this new MusicXML file with Dorico or Sibelius, then the pitches are also shown correctly there. Hm.
I attached for compleness both the original MusicXML file created by Synfire, and the one created by Finale from that, but considering the MusicXML version mismatch here, this might be tricky to fix. :headache:
Thu, 2022-10-20 - 09:39 Permalink
BTW: MIDI export inserts a bar-long rest at the beginning (which MusicXML does not).
Thu, 2022-10-20 - 13:45 Permalink
I can confirm. I'm just so used to deleting the first measure that I didn't even report the bug ahahah
Thu, 2022-10-20 - 13:48 Permalink
These kind of things are just scary. But since they cannot do unit testing because of the chosen programming language, we're always going to get critical bugs.
Thu, 2022-10-20 - 13:53 Permalink
Had this already with SF1. And was always in hope this will be fixed ;-)
Thu, 2022-10-20 - 21:23 Permalink
That's the MIDI file standard (at least for arrangements). It may make sense to skip this when exporting only a single instrument or container, but for an entire arrangement this is needed for program changes, controller resets and similar stuff to settle. Also, there's often a count-in, pickup notes, or similar.
Suggestion: You can compensate for that offset in Synfire on the Sync tab, so counting starts on bar 2 for example. No composition should start at physical bar zero. Even more so when you are synchronizing with a DAW. As we are at it, I'll check if that is properly translated to MIDI file export.
@scriabiner: Please, unfounded speculation about engineering details and future bugs doesn't help anyone. Some things are a challenge, others are a boon without which Synfire would have never seen the light of day. What may look straightforward and simple from the outside, took many years of navigating uncharted territory, experimentation, long-term foresight, failure and frustration to get here. And we will not stop there, ok. Comments that can come across as "They don't get it, they're incompetent, it's hopless" only undermine the operation that is supposed to improve the product.
I've had a very bad day, so sorry if that was a bit harsh. No offense intended. Let's get back to topic.
Thu, 2022-10-20 - 21:53 Permalink
Understood. Thanks for your hard work!
Fri, 2022-10-21 - 00:28 Permalink
I was just quoting yourself:
Fri, 2022-10-21 - 00:41 Permalink
> Smalltalk ... has no type checking at compile time
Don't want to be pedantic, but this has absolutely nothing to do with the ability have unit tests as you seemingly suggested. For example, Python -- arguably currently the most popular language -- has the same deficit, and still has a whole collection of unit test libraries available. Sorry, don't want to futher fan the flames here, quite on the contrary... Apologies if this was in any way offensive.
Fri, 2022-10-21 - 14:21 Permalink
We do have lots of unit tests for data structures and foundational classes. More complex tasks like XML export are hard to test systematically, unless you have lots of human resources to throw at it.
The issues caused by lack of strong typing are easy to fix. It's not fatal or disastrous in any way, it's just an extra hoop to jump through. On the other hand we are able to code while the program is running: Edit rendering code while music is playing, or edit UI code while the windows are open. What takes weeks in C++ can be accomplished in mere hours with Smalltalk.
Fri, 2022-10-21 - 14:27 Permalink
Can't reproduce. Static pitch symbols render XML as expected here. Do you have a simple arrangement do demonstrate the issue?
Mon, 2022-10-24 - 16:57 Permalink
> Can't reproduce.
Thanks for taking the time to check. Attached is a 2 bar example demonstrating the problem (Synfire project and resulting MusicXML file, the latter wrapped in a zip file so it can be uploaded).
For completeness and a quick check, there are some related screen shots too.
Mon, 2022-10-24 - 20:51 Permalink
A new version is online. Changes are now listed here, as usual.
We can continue posting here, if you want.
Mon, 2022-10-24 - 21:14 Permalink
With the download I experience again and again a network error. Last time it was the same.
Mon, 2022-10-24 - 21:36 Permalink
The logs show "Connection reset by peer". Your browser seems to abort the download.
Mon, 2022-10-24 - 21:45 Permalink
It looks like Norton Antivirus Firewall did this. Also with a different browser there was this issue. Disabling Norton did the trick.
Tue, 2022-10-25 - 22:37 Permalink
Hi, I'm still wondering if there is or might be an option to define own plugin paths on the Mac version of Synfire 2.0.11.
My Issue.... I almost can't use Synfire anymore because when I launch it and need the Audio Engine it is ALWAYS scanning my PlugIns, and I got a bunch .. I have to wait almost 25 minutes until the scanning is completed. And when I close Synfire and relaunch it.. same happens again.
So, it would be cool to define alternative PlugIn paths where I only put in those PlugIns I need for Synfire or even better there is already a solution I overlooked.
Or an option, that I can define if Synfire re-scan my PlugIns or not and remembers the last scan and ignoring changes for new PlugIns.
Using: Monterey 12.6.1 (ARM)
Tue, 2022-10-25 - 23:39 Permalink
I am using Windows and don't know if on Mac it is the same, but I can define the folders and I think it caches the found plugin as it takes only long time once.
Wed, 2022-10-26 - 02:01 Permalink
Thank you Andreas :)
awesome :) somehow I was scared to click that button because I always thought it will start the scan process :)
ok, I deselected some VST Paths and ticked off the re-scan, but it still re-scans my AU plugins which I couldn't find an option to tick them off :(
edit: after 30 minutes of waiting that the AU scan finished it started with the VST scan again .. to be honest ..it's frustrating .. it ignores my settings .. why the engine is scanning when I ticked all off?
Wed, 2022-10-26 - 07:14 Permalink
Hmm. I agree to you, it sounds like wrong behavior.
By the way, I also had to search for that setting and assumed it to be in a kind of "vst settings or path section". That 2 kind of preferences areas was always confusing to me. And yes the name also indicated to me that the scan will start immediately and I did not want to start a scan as it needs for me also 10-20 minutes. A different title would help to avoid that misunderstanding.
Wed, 2022-10-26 - 09:05 Permalink
Hi, I have the same problem but having done the scan process on the preferences tab the loading time is very quick, I think there is another post about this!
Wed, 2022-10-26 - 11:23 Permalink
Well after now 1 Hour :( I finally had the chance to go back to the settings. What I noticed, it reverts all changes, it doesn't matter what I delete or uncheck. When I close the preference window and go back, all is ticked on again and all the PlugIn Paths which I deleted or changed are back :(
Also, I deleted ScannedPlugins64.xml which I found in another forum post, didn't help .. starts immediately the AU scan again.
Wed, 2022-10-26 - 11:57 Permalink
On macOS the plugin paths cannot be changed because they are mandatory. Sorry if the dialog doesn't block that.
It is required to let the scan run "from scratch" to its end once. Then it will not restart automatically anymore.
Wed, 2022-10-26 - 12:05 Permalink
Unfortunately it is restarting every time :(
Wed, 2022-10-26 - 12:36 Permalink
Could it be a file permission thing? Is it saving any setting?
Wed, 2022-10-26 - 12:45 Permalink
Ok, I deleted the preference file and I deleted the cognitone folder in the user library folder, and it so far did rebuild the folder and the preference file, so I have to wait another hour again to check ;)
I greatly appreciate your support AndreasHe, thank you :)
Wed, 2022-10-26 - 14:30 Permalink
@tanders: If you look in the XML file, you see C and D exported correctly. Why MuseScore renders them as the same pitch, I have no idea. Probably intended for percussion.
Wed, 2022-10-26 - 16:20 Permalink
Hm, strange. I can see the pitches C and D in the XML file. However, perhaps something concerning these pitches is wrong in the exported format? I just tried opening this file in Dorico, and it also cannot read these pitches and instead displays constant pitches. See attached screen shot.
Wed, 2022-10-26 - 17:06 Permalink
I found a workaround, though it is not pretty. When I open this MusicXML file in Finale (venerable version 2012) then the pitches are displayed correctly. If I now export this Finale file into MusicXML version 2 (does also work with version 1, but not with version 3), and finally open this new MusicXML file with Dorico or Sibelius, then the pitches are also shown correctly there. Hm.
I attached for compleness both the original MusicXML file created by Synfire, and the one created by Finale from that, but considering the MusicXML version mismatch here, this might be tricky to fix. :headache:
Wed, 2022-10-26 - 17:37 Permalink
It's probably the (unpitched) percussion instrument specified in the file that is handled differently form pitched instruments.
Wed, 2022-10-26 - 18:02 Permalink
If this could be fixed by not specifying an unpitched instrument, that would be welcome. Thanks for your help.