Whenever the library rack device is changed by adding a new channel for example, all the existing phrase pool assignments targeting that device get assigned to the new channel.
I may have to wait for 2 secs or more until the selection is shown and effective.
Ouch. I'll have a deep look at thread synchronization. There must be something specific to Windows that gets in the way here. There is a delay with Drones linked in a DAW. It should not occur standalone.
The UI lag didn't come up much in the past because Synfire performs reasonably well here on Windows, even in VMWare Fusion on the Mac at 4K. I wonder what's slowing it down so much. The Shift parameter example is crazy. It just draws lines, nothing special. Your screen resolution is not big either, I'm working on three monitors 5K and 2x 4K all day.
Whatever, I don't think debating the internals of UI architecture makes much sense. Things look simple from the outside and are complex under the hood. Maintaining an asynchronous queue with deferred display updates (as scriabiner suggested) is extreme stuff. You can do that when the output is confinded to a single view and is separate from the data model (e.g. video, graphics), but when you are displaying deep data structures and the user runs ahead of the queue, the views for which updates are pending may no longer exist at the time they come due (i.e. user switched elsewhere). That's just one example I know off the top of my head. There's more to it. Sometimes the best way to maintain consistency is to wait for the data to be ready for display.
Let's stop here with tech. I got the point and will see what I can do.
> I may have to wait for 2 secs or more until the selection is shown and effective.
I should add that I saw such very long waiting times in the first releases of Synfire 2, then not for some time, and recently again. It might be triggered when certain functionality is used, but so far I don't know what that is, but early on and recently again I was playing around with factories when this happened. Of course I am not sure that is related, though.
Maintaining an asynchronous queue with deferred display updates
Actually, I was simply suggesting that anything audio-related should be done separately from the GUI.
In regard to drawing stuff on screen alone, I would've thought that it is obvious that if you are watching measure 84 with zoom at X%, you won't draw measures 1 to ~60, and ~90 to ~200, right?? That's absolutely basic and obvious and not hard to do, so I'm pretty sure it's already done this way. If you meant more complex stuff, it shouldn't actually be needed, in order to have an instantly responsive GUI. So it's clear that there are some other issues, which I hope you can successfully debug.
The hard part is data model related, i.e. when you move a container quickly and don't want to wait until the data structure is fully updated. Parameters can't be (re)displayed until they have traversed the entire container hierarchy to gather required information. Of course that information is cached, but every move flushes this cache. And yes, moving a figure segment also flushes that cache. There is a lot more than "drawing" involved here.
A DAW reponds fast because it has little to rebuild after a change: MIDI is static and flat, audio is static and flat.
Until they have traversed the entire container hierarchy to gather required information.
If you have a good system of traversing vertically, through pointers assigned to the container itself for it to know who are its neighbors, that would save a ton of time. Maybe assigning those pointers could be done when moving containers around, to the advantage of Figure editing. And moving containers around may not get any additional lag, it could even improve, if, when moving them, the moved container doesn't read the whole arrangement but it copies the pointers from the other containers that are located where it's dropped after dragging.
If you're changing something that is on "Repeat mode", you will already know which other containers needs to update, and from which X position, because such information would already be in the container itself.
But, I mean, one would expect Synfire to already behave similarly, since its main feature is the idea of containers, hence why I thought it was the GUI.
There is a lot more than "drawing" involved here.
This doesn't explain though why the Shift parameter has insane lag compared to simply switching to the Figure view, staying exactly in the same screen view??
> every move flushes this cache. ... There is a lot more than "drawing" involved here.
So, moving a symbol or figure requires immediately updating information like resulting pitches or other intermediate pieces of information, so that later for real-time playback such information is ready or can be computed more quickly?
Are there perhaps additional such computations required when editing the result of a factory? Because that was what I was doing when things became extremely slow: not editing "standard figures" (created in ways available already for version 1), but moving around symbols etc. of figures that resulted from factories with various customisation.
Of course there is no physical copying involved with updates and all objects are "pointers" only anyway.
If you're changing something that is on "Repeat mode", you will already know which other containers needs to update, and from which X position, because such information would already be in the container itself.
I appreciate your thoughts, but there is no "if then else" logic involved at all. Synfire is recursively looking from the bottom towards the top (visually speaking), where parameters partially hide others higher up in the hierarchy. The result is a virtual parameter with references that get rendered in the view while using different colors depending on read-only/alias/inherited/etc. The container cashes this information.
The current foreground parameter is a no-brainer. However, Synfire also needs to know what to show in the background, or beyond the end of the container bounds, or the looped span, before anything can be displayed. Because, obviously, you can draw the foreground only after drawing the background.
If you disable Global Parameter Shadow, that might save time in some situations.
This doesn't explain though why the Shift parameter has insane lag compared to simply switching to the Figure view, staying exactly in the same screen view??
Correct. I have not yet the slightest idea. There must be some unnecessary computing going on, like an attempt to express all values as note durations in terms of fractions, dots and whatnot, as is done for notation export. The potential side effects of a system with 3,000+ classes are quite manifold.
If you disable Global Parameter Shadow, that might save time in some situations.
Uh... this improved a lot moving containers, the Shift parameter (only horizontally though, e.g. if I scroll down it lags the same), and clicking the tools buttons.
I mean, the "shadows" are actually useful, but as a workaround, disabling them does indeed improve responsiveness.
I've also noticed that disabling audio feedback slightly improves adding new notes (while it doesn't seem to affect other things), so it looks like that the "no-brainer" audio thing is not really that much no-brainer; I would prefer to get the sound later, but to be able to quickly see the note that I've placed.
So, I would say that the lag issue could be reduced to:
Fix Global Parameter Shadow somehow
Fix that gray rectangle when moving containers, and fix lag when dropping a container to a given position (after mouse release).
Fix audio feedback slowing down inserting new symbols; then, it would still be not instantaneous, but acceptable I think.
Then there are all the other issues in the video, but those in theory should be easier to fix compared to the lag problem.
your solution for audio feedback would hurt those that like to play in their figures via midi.
Also I'd be careful of dropping useful features across all platforms if the lag is windows specific. Maybe they should be options.
In the library editor, using short cuts for individual symbols actually affects its phrase in the library. For example, selecting a symbol and pressing Ctrl-D does not duplicate the symbol, but the phrase, and pressing Ctrl-X does not delete the symbol but is whole phrase (with seemingly no way to undo!). The relevant short cuts are actually listed in the context menu of the symbols though. At least selecting the relevant context menu option works as expected.
I did some benchmarks. A redisplay of a full page of Shift parameters takes 25 ms on macOS while it needs 600 ms on Windows. Another benchmark gives 40 fps refresh rate on macOS but only 6 fps on Windows. With roughly 10% lost to the hypervisor (same hardware), there is still an extreme disparity. Fortunately it's not related to HiDPI or double buffering. It's the rounded rectangles, diagonal lines, dots and circles. The smooth details that make Synfire look the same on both platforms.
If you can live with rectangular buttons and jagged diagonal lines and circles, we can have a faster UI very soon. I however prefer to spend another day or two trying to find a remedy. Something obvious must be going wrong here, like the graphics system accidentally initializing with every call, or similar.
With 2.0.7 we'll also have many new optimizations at a higher level that already improve overall responsiveness, even without a low-level graphics fix. I'm optimistic.
It's been GDI+ that was slowing down graphics on Windows, especially rounded shapes and frequent drawing calls (e.g. data points and the connecting lines). Bypassing GDI+ and using plain GDI for parameter views helps a lot. Still slower than on macOS, but speed has at least increased 400% which is a big deal. Zooming in restores smoothness when you need it, with no noticeable effect on speed. On HiDPI the tiny aliasing is barely noticeable anyway.
Displaying the container hierarchy, global traces and selections efficiently is not trivial. Segments can reach into the container neighborhood, so the code has to deal with many edge cases if we want to redraw as few parameter data as possible during playback and editing (pulled my hair out on some issues, but there we are). It got a much snappier.
I hope to finish testing 2.0.7 very soon. It's about time.
Fingers crossed for the next version. This feels like it could be a huge win for the collective efforts of the Cognitone team and the extremely diligent beta testers on this thread. Thank you! It's more than 20 years since I last did any proper development work but I feel the pain of everyone involved. There was a bit of "creative tension" back there but it looks like it may have produced the goods. Good luck - and to everyone working on the lagging thing: thank you for improving a fantastic product!
I still can't reproduce popup menus opening outside the screen. No matter how close to the margins I open them, they are moved to within screen bounds as expected. Also, that odd look with slightly shifted/bordered menu items doesn't occur here.
Is this issue experienced by many users? Does it relate to specific HiDPI scales?
Tried to export the example song "Rachels Radiation" as musicxml and Lilypond file. The musicxml file could at least not be correctly interpreted by Musescore (OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.6.2.548021803, revision: github-musescore-musescore-3224f34)
Getting the error message:
Takt 18, Notenzeile 2 unvollständig. Erwartet: 69/64; Gefunden: 2136/1920
Takt 23, Notenzeile 7 unvollständig. Erwartet: 19/16; Gefunden: 768/640
and the spare few notes that are shown don't resemble the piece.
And for lilypond (2.22.2) I get lots of syntax errors (here the last ones):
...
If notation rendering works reliably this will be a great addition to Synfire! Perhaps one could even have a live updating score window directly inside Synfire? (Could be read-only as a first step)
I don't know the piece, but if you have tuplets, yes, you're going to have a hard time. If you don't, exporting to notation has improved a bit, but you have to manually set the quantization settings until you get a green status. Check the esporting panel, there are new tabs and options.
If notation rendering works reliably this will be a great addition to Synfire!
Welcome to the club...
Perhaps one could even have a live updating score window directly inside Synfire?
That will very likely never be done if you also want it editable, but thanks to LilyPond, it's actually a rather simple thing to do; however it will be very slow because LilyPond must compile at each change. I don't think we will ever see something like that, but it's not really necessary: with the GUI as it is, a lot of notation support could already be done in various way.
Rachels Radiation has to much chaotic rhythm and messy quantization for notation export. You need to be very minimalistc and strict (rhythm wise) from the start if you want to produce notation output. There's a section in the user manual about this:
Thanks for the feedback! Ok, sounds plausible, will play around with more simplistic material. Would of course be nice if Synfire would still generate valid musicxml/lilypond files in case the piece is too complex, so one can potentially fix it in the notation software/with an editor (or if it is clear that no feasible result will come out to refuse the conversion and not generate any files).
Notating a modern piece with non-standard, flexible rhythmic measures can also be challenging for a human. An advanced notation AI that excels at arbitrary MIDI to notation conversion would be a really neat feature for Synfire 2.5 ;)
Sat, 2022-07-02 - 11:43 Permalink
Bug Report: Library App
Whenever the library rack device is changed by adding a new channel for example, all the existing phrase pool assignments targeting that device get assigned to the new channel.
Sat, 2022-07-02 - 16:22 Permalink
Tabs are the least important. Please try to simulate the various things I've shown in the video, and report your experience.
I'm especially curious about the Shift parameter.
Sat, 2022-07-02 - 18:52 Permalink
Thanks for the new bug reports everyone.
Ouch. I'll have a deep look at thread synchronization. There must be something specific to Windows that gets in the way here. There is a delay with Drones linked in a DAW. It should not occur standalone.
The UI lag didn't come up much in the past because Synfire performs reasonably well here on Windows, even in VMWare Fusion on the Mac at 4K. I wonder what's slowing it down so much. The Shift parameter example is crazy. It just draws lines, nothing special. Your screen resolution is not big either, I'm working on three monitors 5K and 2x 4K all day.
Whatever, I don't think debating the internals of UI architecture makes much sense. Things look simple from the outside and are complex under the hood. Maintaining an asynchronous queue with deferred display updates (as scriabiner suggested) is extreme stuff. You can do that when the output is confinded to a single view and is separate from the data model (e.g. video, graphics), but when you are displaying deep data structures and the user runs ahead of the queue, the views for which updates are pending may no longer exist at the time they come due (i.e. user switched elsewhere). That's just one example I know off the top of my head. There's more to it. Sometimes the best way to maintain consistency is to wait for the data to be ready for display.
Let's stop here with tech. I got the point and will see what I can do.
Sat, 2022-07-02 - 19:08 Permalink
> I may have to wait for 2 secs or more until the selection is shown and effective.
I should add that I saw such very long waiting times in the first releases of Synfire 2, then not for some time, and recently again. It might be triggered when certain functionality is used, but so far I don't know what that is, but early on and recently again I was playing around with factories when this happened. Of course I am not sure that is related, though.
Sat, 2022-07-02 - 21:00 Permalink
Sorry but just to clarify:
Actually, I was simply suggesting that anything audio-related should be done separately from the GUI.
In regard to drawing stuff on screen alone, I would've thought that it is obvious that if you are watching measure 84 with zoom at X%, you won't draw measures 1 to ~60, and ~90 to ~200, right?? That's absolutely basic and obvious and not hard to do, so I'm pretty sure it's already done this way. If you meant more complex stuff, it shouldn't actually be needed, in order to have an instantly responsive GUI. So it's clear that there are some other issues, which I hope you can successfully debug.
Thank you.
Sat, 2022-07-02 - 21:15 Permalink
Audio-related is a no brainer.
The hard part is data model related, i.e. when you move a container quickly and don't want to wait until the data structure is fully updated. Parameters can't be (re)displayed until they have traversed the entire container hierarchy to gather required information. Of course that information is cached, but every move flushes this cache. And yes, moving a figure segment also flushes that cache. There is a lot more than "drawing" involved here.
A DAW reponds fast because it has little to rebuild after a change: MIDI is static and flat, audio is static and flat.
Mon, 2022-07-18 - 01:28 Permalink
If you have a good system of traversing vertically, through pointers assigned to the container itself for it to know who are its neighbors, that would save a ton of time. Maybe assigning those pointers could be done when moving containers around, to the advantage of Figure editing. And moving containers around may not get any additional lag, it could even improve, if, when moving them, the moved container doesn't read the whole arrangement but it copies the pointers from the other containers that are located where it's dropped after dragging.
If you're changing something that is on "Repeat mode", you will already know which other containers needs to update, and from which X position, because such information would already be in the container itself.
But, I mean, one would expect Synfire to already behave similarly, since its main feature is the idea of containers, hence why I thought it was the GUI.
This doesn't explain though why the Shift parameter has insane lag compared to simply switching to the Figure view, staying exactly in the same screen view??
Sat, 2022-07-02 - 22:07 Permalink
> every move flushes this cache. ... There is a lot more than "drawing" involved here.
So, moving a symbol or figure requires immediately updating information like resulting pitches or other intermediate pieces of information, so that later for real-time playback such information is ready or can be computed more quickly?
Are there perhaps additional such computations required when editing the result of a factory? Because that was what I was doing when things became extremely slow: not editing "standard figures" (created in ways available already for version 1), but moving around symbols etc. of figures that resulted from factories with various customisation.
Sun, 2022-07-03 - 12:09 Permalink
Of course there is no physical copying involved with updates and all objects are "pointers" only anyway.
I appreciate your thoughts, but there is no "if then else" logic involved at all. Synfire is recursively looking from the bottom towards the top (visually speaking), where parameters partially hide others higher up in the hierarchy. The result is a virtual parameter with references that get rendered in the view while using different colors depending on read-only/alias/inherited/etc. The container cashes this information.
The current foreground parameter is a no-brainer. However, Synfire also needs to know what to show in the background, or beyond the end of the container bounds, or the looped span, before anything can be displayed. Because, obviously, you can draw the foreground only after drawing the background.
If you disable Global Parameter Shadow, that might save time in some situations.
Correct. I have not yet the slightest idea. There must be some unnecessary computing going on, like an attempt to express all values as note durations in terms of fractions, dots and whatnot, as is done for notation export. The potential side effects of a system with 3,000+ classes are quite manifold.
Will do some profiling.
Sun, 2022-07-03 - 13:18 Permalink
No lag on shift for me, am I supposed to so something, like add 20 containers or s9mething?
Tue, 2022-07-05 - 13:02 Permalink
Uh... this improved a lot moving containers, the Shift parameter (only horizontally though, e.g. if I scroll down it lags the same), and clicking the tools buttons.
I mean, the "shadows" are actually useful, but as a workaround, disabling them does indeed improve responsiveness.
I've also noticed that disabling audio feedback slightly improves adding new notes (while it doesn't seem to affect other things), so it looks like that the "no-brainer" audio thing is not really that much no-brainer; I would prefer to get the sound later, but to be able to quickly see the note that I've placed.
So, I would say that the lag issue could be reduced to:
Then there are all the other issues in the video, but those in theory should be easier to fix compared to the lag problem.
Mon, 2022-07-04 - 01:30 Permalink
your solution for audio feedback would hurt those that like to play in their figures via midi.
Also I'd be careful of dropping useful features across all platforms if the lag is windows specific. Maybe they should be options.
Mon, 2022-07-04 - 12:36 Permalink
Sure. A checkbox in Preferences similar to FL Studio's "Safe overloads" option. So one can decide if to give priority to GUI or audio.
Wed, 2022-07-06 - 11:47 Permalink
In the library editor, using short cuts for individual symbols actually affects its phrase in the library. For example, selecting a symbol and pressing Ctrl-D does not duplicate the symbol, but the phrase, and pressing Ctrl-X does not delete the symbol but is whole phrase (with seemingly no way to undo!). The relevant short cuts are actually listed in the context menu of the symbols though. At least selecting the relevant context menu option works as expected.
This is for Win 10.
Thu, 2022-07-07 - 17:47 Permalink
I did some benchmarks. A redisplay of a full page of Shift parameters takes 25 ms on macOS while it needs 600 ms on Windows. Another benchmark gives 40 fps refresh rate on macOS but only 6 fps on Windows. With roughly 10% lost to the hypervisor (same hardware), there is still an extreme disparity. Fortunately it's not related to HiDPI or double buffering. It's the rounded rectangles, diagonal lines, dots and circles. The smooth details that make Synfire look the same on both platforms.
If you can live with rectangular buttons and jagged diagonal lines and circles, we can have a faster UI very soon. I however prefer to spend another day or two trying to find a remedy. Something obvious must be going wrong here, like the graphics system accidentally initializing with every call, or similar.
With 2.0.7 we'll also have many new optimizations at a higher level that already improve overall responsiveness, even without a low-level graphics fix. I'm optimistic.
Thu, 2022-07-07 - 18:22 Permalink
Thank you!
Thu, 2022-07-07 - 20:03 Permalink
Thank you for delving into this.
Wed, 2022-07-13 - 21:12 Permalink
Update:
It's been GDI+ that was slowing down graphics on Windows, especially rounded shapes and frequent drawing calls (e.g. data points and the connecting lines). Bypassing GDI+ and using plain GDI for parameter views helps a lot. Still slower than on macOS, but speed has at least increased 400% which is a big deal. Zooming in restores smoothness when you need it, with no noticeable effect on speed. On HiDPI the tiny aliasing is barely noticeable anyway.
Displaying the container hierarchy, global traces and selections efficiently is not trivial. Segments can reach into the container neighborhood, so the code has to deal with many edge cases if we want to redraw as few parameter data as possible during playback and editing (pulled my hair out on some issues, but there we are). It got a much snappier.
I hope to finish testing 2.0.7 very soon. It's about time.
Wed, 2022-07-13 - 22:33 Permalink
Fingers crossed for the next version. This feels like it could be a huge win for the collective efforts of the Cognitone team and the extremely diligent beta testers on this thread. Thank you! It's more than 20 years since I last did any proper development work but I feel the pain of everyone involved. There was a bit of "creative tension" back there but it looks like it may have produced the goods. Good luck - and to everyone working on the lagging thing: thank you for improving a fantastic product!
Thu, 2022-07-14 - 07:11 Permalink
+1 on these well-expressed sentiments
Thu, 2022-07-14 - 13:11 Permalink
Good news.
Take your time.
Fri, 2022-07-15 - 18:15 Permalink
I still can't reproduce popup menus opening outside the screen. No matter how close to the margins I open them, they are moved to within screen bounds as expected. Also, that odd look with slightly shifted/bordered menu items doesn't occur here.
Is this issue experienced by many users? Does it relate to specific HiDPI scales?
Sat, 2022-07-16 - 15:18 Permalink
Will check.
Sat, 2022-07-16 - 14:12 Permalink
Is it possible that multiple monitors are declared but not connected? Or maybe for some reason the monitor size reported to Synfire isn't correct.
Sat, 2022-07-16 - 15:27 Permalink
Turns out that yes, that's the cause.
I don't know why I didn't try before, I changed the scale only to test other bugs, but yep, with 100%, popups work fine.
Sun, 2022-07-17 - 00:40 Permalink
Tried to export the example song "Rachels Radiation" as musicxml and Lilypond file. The musicxml file could at least not be correctly interpreted by Musescore (OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.6.2.548021803, revision: github-musescore-musescore-3224f34)
Getting the error message:
Takt 18, Notenzeile 2 unvollständig. Erwartet: 69/64; Gefunden: 2136/1920
Takt 23, Notenzeile 7 unvollständig. Erwartet: 19/16; Gefunden: 768/640
and the spare few notes that are shown don't resemble the piece.
And for lilypond (2.22.2) I get lots of syntax errors (here the last ones):
...
Rachels-Radiation.ly:360:44: Fehler: syntax error, unexpected STRING
\new Voice = "voiceInstBFOneLocal"
\voiceInstBFOne
Rachels-Radiation.ly:360:44: Fehler: Textzeichen außerhalb von Textbeschriftungs- oder \lyricmode-Umgebung
\new Voice = "voiceInstBFOneLocal"
\voiceInstBFOne
Rachels-Radiation.ly:322:1: Fehler: Fehler gefunden, musikalischer Ausdruck wird ignoriert
<<
schwerer Fehler: gescheiterte Dateien: "Rachels-Radiation.ly"
If notation rendering works reliably this will be a great addition to Synfire! Perhaps one could even have a live updating score window directly inside Synfire? (Could be read-only as a first step)
Sat, 2022-10-01 - 20:59 Permalink
I don't know the piece, but if you have tuplets, yes, you're going to have a hard time. If you don't, exporting to notation has improved a bit, but you have to manually set the quantization settings until you get a green status. Check the esporting panel, there are new tabs and options.
Welcome to the club...
That will very likely never be done if you also want it editable, but thanks to LilyPond, it's actually a rather simple thing to do; however it will be very slow because LilyPond must compile at each change. I don't think we will ever see something like that, but it's not really necessary: with the GUI as it is, a lot of notation support could already be done in various way.
Please see (https://users.cognitone.com/topic/notation-export) for the "official" dedicated thread,
(https://users.cognitone.com/topic/my-list-suggestions) for my "Voices" idea
and (https://users.cognitone.com/topic/basic-notation-features-eg-accents) for my basic notation support feature request.
Sun, 2022-07-17 - 19:35 Permalink
Rachels Radiation has to much chaotic rhythm and messy quantization for notation export. You need to be very minimalistc and strict (rhythm wise) from the start if you want to produce notation output. There's a section in the user manual about this:
(https://docs.cognitone.com/synfire/EN/workflows/PerformanceVsNotation.h…)
Sun, 2022-07-17 - 23:21 Permalink
Thanks for the feedback! Ok, sounds plausible, will play around with more simplistic material. Would of course be nice if Synfire would still generate valid musicxml/lilypond files in case the piece is too complex, so one can potentially fix it in the notation software/with an editor (or if it is clear that no feasible result will come out to refuse the conversion and not generate any files).
Notating a modern piece with non-standard, flexible rhythmic measures can also be challenging for a human. An advanced notation AI that excels at arbitrary MIDI to notation conversion would be a really neat feature for Synfire 2.5 ;)