Dear scriabiner: Honest & open feedback, take no offense:
I admire and really appreciate your kind effort to contribute to advancing the system, but your threads and the way you update them is so rigid, deep and structured that they are hard to digest for an ordinary user being, at least for me. I assume they are helpful for Andre, but sorry I cannot stand them.
couldn't someone have told me that those bugs are not being experienced?
Maybe others feel same and thus shy away and therefore feedback of community is limited. Please give it a thought, maybe more digestable pieces with less and more accessible lines.
No, I understand, you have a point, they're more geared for the devs.
I could have simply opened a thread asking users their experience with lag ang the GUI. But I thought it was established that everyone on Windows was having issues.
I've followed your suggestions, and I've updated everything (uninstalled and re-installed drivers), and I also did a test where I restarted the PC and then opened Synfire and absolutely nothing else, in order to avoid conflicts or things like that. And Synfire has been re-installed, btw.
Well, nothing changed.
The lag is there: a new project reacts instantly, but as soon as you have around 10/15 containers (with max 3 measures each), and only two instruments, it starts lagging. Less than a second, but if you know anything about lag you know that you end up crazy, it's extremely annoying (hence why I'm mad a lot of times talking about this program, sorry), you end up crazy with just a few milliseconds, and in this case it's not a few. The popup menus are still going off-screen. I mean, I have no idea at this point. I'm even using an SSD and a recent GPU, lol.
Every other software works perfectly on my PC, FL Studio, Dorico, non-music related programs, everything responds instantly and my menus don't go off-screen.
I have never had a worse experience with a software program, and this is paid software, so I hope you can understand my disappointment.
I'm not saying that other users are lying of course. However, if Synfire works on one system, it doesn't necessarily mean that there aren't issues, that result in some other system getting all messed up.
I'm on Windows 10 64, not 11, btw, which is supported until 2025; fully updated.
Will try to make a video as soon as I have the time and the resources, I don't usually record the desktop, so I have to do it correctly.
Well, I must say that I can confirm most of these issues on Windows. Editing indeed can be a pain, especially when there is a lot of work to be done. After 10+ years with the software, I've gotten used to it to some extent, but I admit it can be annoying.
For example, if you want to move a container, you have to wait a second after selecting it before you move the mouse pointer. Otherwise the container will be dragged 5 centimeters behind the mouse pointer. Things like that.
We briefly considered setting up a public bug tracking system, but it was deemed too distracting at this point (we have one in-house). The intense "grilling" is actually great within a team (some teams do role playing to achieve that). But it's obviously prone to misunderstandings without non-verbal contact, and even more so in a public forum.
I can somehow relate to outbursts of frustration. The other day I wanted to shove my desk out the window and smash the iMac to pieces. But that wasn't because Synfire or Windows. It was about Apple ;-)
You should be able to select a vertical bar, not a point. It's bad design imho.
Polyphony requires points ("velocity chords"), unless you know a way to stack multiple bars in a 3rd dimension. You can select any vertical and horizontal partial range, as with bars. Functionally, there isn't much of a difference besides the look.
Andre would've told me that I am the only Windows user experiencing these problems. Quite the opposite, he seemed to acknowledge that there are issues with the Windows version.
Nobody else reporting doesn't mean everybody is happy. So after the little survey we had here, I'm relieved.
I agree with you that the UI could be more responsive on Windows. I'm primarily working on macOS and notice the difference between the platforms everytime I switch. I sense that most programs are slower on Windows but chalked that up to hardware specifics. I'm not happy with it yet, but I think it is absolutely workable, even with lots of containers and instruments. But what's fast enough for one person is slow for another.
If the performance is so bad that you can't even use a dozen or so containers, there is probably something else going wrong.
FYI: On Windows, Synfire needs to render all graphics to a bitmap first, then swaps it to the screen. Windows doesn't support transactional double buffering like macOS, which is needed to eliminate flicker. On HiDPI monitors, these bitmaps can be huge and they possibly slow down the "frame rate" much. I wouldn't be surprised if different PC hardware & drivers may lead to different user experiences.
That said, we'll have another look at the double buffering.
I should also note that after an exception ("crash") the double buffering is sometimes compromised and slows down significantly.
That's hard to meet. I don't know many regular Windows programs this fast. According to my experience something around 50-80 ms is normal, depending on load. Of course, a 50 ms delay with typing code would drive me crazy. Switching tabs not so much. So I wonder which lag you think is most annoying and maybe tackle that with priority:
Switching the main tabs (pages) has a lag because the UI is laid out from scratch. It gets faster over time because the code is cached. Others tabs should be fast.
Scrolling the track sheet can get slow with lots of long figures visible at a time.
There is lag when you select and transpose segments (audio feedback enabled), because the entire arrangement needs to be re-rendered with every move, as any parallel or parent container could possibly influence the result. Not sure how to speed this up yet. Lucky DAW developers don't face such challenges.
Drag & drop. As Jürgen reported, dragging a container off too fast makes the rectangle appear offset from the mouse pointer. There may be other instances I'm not aware of. The rectangle shape is no longer used that much.
The orange playhead cursor is sluggish.
Drawing figures and parameters with the Line, Freehand, Shape tools. I haven't noticed any lag, but your experience may vary.
An open Help Browser slows down the response a bit.
Let's make this a small survey. Which is worst, which is tolerable.
I should also note that after an exception ("crash") the double buffering is sometimes compromised and slows down significantly.
No, I know, you told me that in the forum, so I always restart when that happens.
50-80 ms is normal
With Synfire we're talking 200ms to 1 second, especially e.g. with the Shift parameter (because it draws tons of stuff). I'm currently editing the video.
Regardless of numbers, which is difficult to estimate, with Synfire you feel the pain, while with FL Studio and Dorico the response is immediate. FL Studio responded instantly even on old machines and during playback.
3. There is lag when you select and transpose segments (audio feedback enabled), because the entire arrangement needs to be re-rendered with every move, as any parallel or parent container could possibly influence the result. Not sure how to speed this up yet. Lucky DAW developers don't face such challenges.
With audio feedback disabled, you get the exact same issues, it's about drawing the GUI, not the rendering.
In any case, rendering should be done in another thread, and in general, in my opinion, as is done e.g. in Dorico, the sound should come later, the priority is on the editing. Editing should be immediate, otherwise the user wants to smash the PC. When you press play, Dorico takes its time (around 1 second) to calculate the resulting high resolution MIDI output; Synfire should do the same. But again, even with the sound off, the lag is still there, so it's the GUI.
Let's make this a small survey. Which is worst, which is tolerable.
Uh, none of it is tolerable, except maybe switching tabs. The GUI must be instantaneous unless you're going out of your way to e.g. open a Preferences dialog, switching a tab which loads other stuff, changing big things (like instruments, and general main settings about Synfire or the arrangement). Not when you're drawing a note or clicking a button. Even clicking the button for "shape" has a noticeable lag; even though this is the last of the problems, it contributes to the fact that the software feels sluggish.
On Windows, Synfire needs to render all graphics to a bitmap first, then swaps it to the screen.
My god.
Which however doesn't surprise me, because it's perfectly consistent with what I am experiencing. That's why I talked about "bad design choice". Because now you can't go back.
Polyphony requires points ("velocity chords"), unless you know a way to stack multiple bars in a 3rd dimension. You can select any vertical and horizontal partial range, as with bars. Functionally, there isn't much of a difference besides the look.
I'm talking exclusively visually, of course. Internally, they are obviously points. But visually they should be easily clickable, and vertical bars are the way to go, and are in fact "the standard" to edit velocities in software.
Hey Scriabiner. Honestly my friend, I'm not having these problems, and it seems many others are not. But share that video and let's see what the culprit is. It's probably an easy fix, and will help any others in the same boat. In the meantime, cut Andre some slack please.
For proper watching, please consider downloading the file and watching full-screen, even though the quality is low; otherwise it's difficult to notice certain things, like the blue vertical bar of the selection (1 pixel).
Thanks for the video. Some things are lagging worst than expected, others don't seem especially slow, but that's subjective. Your editing speed is certainly extreme. I get that it's to demonstrate the point.
What's your total screen resolution?
vertical bars are the way to go, and are in fact "the standard" to edit velocities in software
Again: Standards are fine but they don't apply here. We are NOT editing the velocities of notes. It's a standalone parameter that requires multiple velocities at the same point in time. And those are best visualized as "chords" of some sort. Not to mention five different modes of interpolation.
With audio feedback disabled, you get the exact same issues
Interesting. On macOS it makes a big difference.
In any case, rendering should be done in another thread
That's already the case. Something may be blocking the UI thread.
My god.
You seem to have never had a look into window servers. Double buffering is not a design decision, it's standard. Only that modern OS do this under the hood much more efficiently than programs can do it themselves. Windows is still stuck in the 1980's with graphics ops writing pixels to the device. With double buffering disabled, you see every single drawing action on screen, which is even worst than lag.
Because now you can't go back.
Fatalistic nonesense. Everything can be changed. We got the source code of language compilers, virtual machines and most libraries. Window's ancient graphics model however can't be changed. Maybe there's a workaround. Or a bug.
Even clicking the button for "shape" has a noticeable lag
The button doesn't do anything except updating the visibility of tools.
If you expect Synfire to keep up with your keyboard's auto-repeat rate no matter which command, I'm afraid that won't happen before we eventually port to C++.
Thanks for the zoom and popup menu demo. Can't yet reproduce the popup issue, though. Menus open all correctly here even at the extreme margins of the screen.
your editing speed is certainly extreme. I get that it's to demonstrate the point.
Please, don't try to find excuses: the user may work extremely slow, but the moment that he clicks, the software must respond instantly. Please install a demo (if you don't have the full version) of FL Studio, and play around with it. I'm suggesting it for real, I'm not kidding. Play around with it for a while, on Windows. Then, on the same system, start Synfire. Users are used to that kind of response time. And rightly so, it's 2022.
Don't use rendering as an excuse either, because in the moment of editing, FL Studio and Synfire are (or should be) the same: the complex harmonic rendering can be done later in a parallel thread and/or when activating playback.
What's your total screen resolution?
If the user wants to use Synfire at 4K, maximized, it should be able to do it and he should have instant response time.
Again: Standards are fine but they don't apply here. We are NOT editing the velocities of notes. It's a standalone parameter that requires multiple velocities at the same point in time. And those are best visualized as "chords" of some sort. Not to mention five different modes of interpolation.
You don't understand, I'm not talking about how it's done internally: points at the same vertical positions are fine (they are needed!). I'm talking about visual editing. Please open Dorico and edit the velocities in the piano-roll, and notice that they are displayed as overlapping vertical bars. And exactly because of that, vertical bars are the perfect GUI solution to be able to select one specific bar, without also selecting the other one at the same vertical position, because, if they have different values, you simply click in the area of the bar that you want, leaving out the other bar; so, you get the same advantages of having points, but in addition you have a better method of letting the user select a specific bar without also selecting the other ones by mistake.
I mean, thinking about it, it doesn't matter that much: the real problem is that you cannot map a lower velocity to a higher note. That's the obvious dealbreaker. But that is related to voices, which is a very important missing feature, even though I appreciate the new editing mode where you can see the other instruments in the background, it's a good enough workaround, for now.
With audio feedback disabled, you get the exact same issues. > Interesting. On macOS it makes a big difference.
Yup, no difference here on Windows. Which makes sense, because the issue is GUI drawing, not the rendering of MIDI data.
That's already the case (i.e. parallel rendering thread). Something may be blocking the UI thread.
Like... what, aside from the issues with the programming language (or whatever it is)?
window servers
Oh, ok. The way you said it, I thought it was something bad. Well, I don't know then. I mean, every other software in existence works fine on Windows, so I'm not sure where the problem lies, then.
Fatalistic nonesense. Everything can be changed. We got the source code of language compilers, virtual machines and most libraries. Window's ancient graphics model however can't be changed. Maybe there's a workaround. Or a bug.
Ok. What I meant is that you said that it would take re-programming the GUI in C++, but if there are other ways to go, that's good news!
The button doesn't do anything except updating the visibility of tools.
If you expect Synfire to keep up with your keyboard's auto-repeat rate no matter which command, I'm afraid that won't happen before we eventually port to C++.
Nope. Clicking a button sometimes takes like 200ms. So we're not talking a small-time. Aside from numbers, if you click a button and can notice, very clearly, that it takes time for it to change its image to "ON", it means that something is wrong with the drawing on the screen. The buttons are not the worse thing, of course, but they are a good indication, because there's certainly very few lines of code when you simply select a tool, so if the GUI doesn't respond instantly, it's a very good indication that something is wrong. Clicking a button shouldn't have more than 20ms delay: numbers aside, when it is noticeable, regardless of the number of ms, something is wrong.
Can't yet reproduce the popup issue, though. Menus open all correctly here even at the extreme margins of the screen.
Oh, ok...
That's bad news. If there's anything that I can do in regard to provide data and stuff, let me know. I can send, via email, specifications, etc.
It seems velocity edits with the H-(yper) mode cannot be undone (they are seemingly not part of the undo-history). Not sure whether this is an issue new for the last version, but for me at least this is a serious issue.
Another question: The "Hand Symbol" that now appears when dragging a selected symbol or phrase...is that really necessary? Not only does this look totally childish, it also disturbs editing. Because this hand obscures the point where you want to place the symbol. It should at least be possible to disable that.
I can confirm that I am experience lagging as well. For example, when selecting a figure or symbol (clicking with the mouse) I may have to wait for 2 secs or more until the selection is shown and effective. This is when editing some very short figures in a library with hardly any figures and on a very powerful WIn 10 machine that has been set up recently over the last view months (lots of music software installed, hardly anything else).
Context: I am used to do something pretty similar to Synfire's music prototyping in code, and compared to that having a GUI is faster, even if it is lagging that much, therefore I am accepting this. Anyway, waiting for > 2 secs after every mouse click does slow done editing (and considering that some clicks are not registered, and certain operations require multiple clicks, a simple operation like grouping two figures can easily take clearly more than 10 secs, and more if certain clicks are not registered correctly). Sometimes it is faster, and sometimes very slow, and I have not understood a pattern yet.
Sometimes a restart of the software can help, but because the rescanning of plugins always takes several minutes on my machine (seemingly in particular rescanning Melda Production plugins seems to take quite some time), I do not want to do restart Synfire too often either.
It might be that this lagging starts after certain operations, e.g., certain factory operations. I will try to keep an eye on whether I notice any pattern there, in case that could help.
Anyway, I don't want to sound too negative. I know that this is pre-release software, created by a small team that breaks new gound -- and I like its main approach. :-)
It might be that this lagging starts after certain operations, e.g., certain factory operations. I will try to keep an eye on whether I notice any pattern there, in case that could help.
No, I never loaded factories when doing the video, and I started with an empty project; factories work quite well for me, I have to say, for what I remember; the generation sure is superfast. It's about how much stuff the software has to draw on screen; which is why with the Shift parameter filled with rubato, which has a lot of green lines and points to draw, the software doesn't manage to draw in time. It may be more complex than that, of course.
I am used to do something pretty similar to Synfire's music prototyping in code, and compared to that having a GUI is faster, even if it is lagging that much, therefore I am accepting this.
[Redacted: useless long rant about the lag]
tl;dr: Yup, it has good unique features and potential, so we use it, but the GUI is a big issue and should really be fixed.
@scriabiner If the problems you highlighted in your video occur for everyone on windows, I'm sure andre would have seen them in testing. If they had been there from day one in version 1 and were unresolvable, I doubt synfire would have been released on Windows. Back when synfire first released the majority of serious computer based musicians and djs used macs, so offering an unusable windows version could have affected total sales for only a small market increase.
I suspect the problem with the GUI lag is not affecting every windows user, so there has to be something different between those affected and those without issues. I suspect there is something in the smalltalk gui code/screen driver that isn't been well handled on certain graphics cards, hardware/firmware revision or driver versions. I've seen instances before where using recent drivers performed worse with older cards depending on what the application was trying to do as the latest drivers are designed to get the data to the gpu as fast as possible and that introduces delays when forced to resort to the cpu as the older hardware doesnt support some feature.
Unless andre can find some solution in the code or from the smalltalk developers, it might need some sort of survey to capture the detail specs of windows users, both those with and without issue. That would give andre and the smalltalk developers something to focus on, or if all else fails enable everyone affected to upgrade/downgrade firmware, drivers or hardware to a setup that works.
> It might be that this lagging starts after certain operations, e.g., certain factory operations.
Last night, when I experienced this severe lag of > 2 secs per mouse click, restarting Synfire greatly reduced that to less than a second. So, there may always be a certain amount of lag at least on some platforms, but it seemingly can get far worse at times, and the latter may depend on certain operations.
I don't think it is fair to compare Synfire with applications like FL Studio, because Synfire targets a much smaller market with its unique features, and I applaud that. As a developer myself, I understand why they use Smalltalk for what they do, and I therefore accept that for this niche market the software has certain downsides like this lag.
For completeness, I think Dorico is a borderline case, also targeting a niche market (professional engravers, composers...) with their advanced notation capabilities, but with a big funder like Steinberg/Yamaha backing a much larger team than Synfire, they were allowed to spend several years just for laying down some great foundation for what they do. And even Dorico seems to recently try to increase its market share by spending serious development efforts on features not really relevant for their initial market (professional engravers).
Switching to the German (or French) UI no longer works for me. Everything remains in English. Not that I use the German UI anymore, but I was curious what changed (maybe you got rid of the annoying term "Harmoniefolge" instead of Progression again?).
My Windows system shows it as a Nvidia GeForce GTX 1650. (My bill actually shows GeForce GTX 1650 WindForce, so I guess that only the graphics processor is by Nvidia, while the card is actually by Gigabyte.)
Wed, 2022-06-29 - 18:25 Permalink
Scriabiner, might be worth checking your GPU drivers are up to date. Make a video of the lag, so we can see what's happening.
Mon, 2022-07-18 - 01:42 Permalink
They are, I'm trying to update everything else just in case.
Wed, 2022-06-29 - 18:29 Permalink
Dear scriabiner: Honest & open feedback, take no offense:
I admire and really appreciate your kind effort to contribute to advancing the system, but your threads and the way you update them is so rigid, deep and structured that they are hard to digest for an ordinary user being, at least for me. I assume they are helpful for Andre, but sorry I cannot stand them.
Maybe others feel same and thus shy away and therefore feedback of community is limited. Please give it a thought, maybe more digestable pieces with less and more accessible lines.
Again, take no offense.
Mon, 2022-07-18 - 01:41 Permalink
No, I understand, you have a point, they're more geared for the devs.
I could have simply opened a thread asking users their experience with lag ang the GUI. But I thought it was established that everyone on Windows was having issues.
Mon, 2022-07-18 - 01:42 Permalink
I've followed your suggestions, and I've updated everything (uninstalled and re-installed drivers), and I also did a test where I restarted the PC and then opened Synfire and absolutely nothing else, in order to avoid conflicts or things like that. And Synfire has been re-installed, btw.
Well, nothing changed.
The lag is there: a new project reacts instantly, but as soon as you have around 10/15 containers (with max 3 measures each), and only two instruments, it starts lagging. Less than a second, but if you know anything about lag you know that you end up crazy, it's extremely annoying (hence why I'm mad a lot of times talking about this program, sorry), you end up crazy with just a few milliseconds, and in this case it's not a few. The popup menus are still going off-screen. I mean, I have no idea at this point. I'm even using an SSD and a recent GPU, lol.
Every other software works perfectly on my PC, FL Studio, Dorico, non-music related programs, everything responds instantly and my menus don't go off-screen.
I have never had a worse experience with a software program, and this is paid software, so I hope you can understand my disappointment.
I'm not saying that other users are lying of course. However, if Synfire works on one system, it doesn't necessarily mean that there aren't issues, that result in some other system getting all messed up.
I'm on Windows 10 64, not 11, btw, which is supported until 2025; fully updated.
Will try to make a video as soon as I have the time and the resources, I don't usually record the desktop, so I have to do it correctly.
Wed, 2022-06-29 - 21:02 Permalink
Record that video, and I'll see if I can help you. And I don't get paid to do so.
You can use (https://obsproject.com) to record.
Wed, 2022-06-29 - 21:11 Permalink
Well, I must say that I can confirm most of these issues on Windows. Editing indeed can be a pain, especially when there is a lot of work to be done. After 10+ years with the software, I've gotten used to it to some extent, but I admit it can be annoying.
For example, if you want to move a container, you have to wait a second after selecting it before you move the mouse pointer. Otherwise the container will be dragged 5 centimeters behind the mouse pointer. Things like that.
Wed, 2022-06-29 - 21:13 Permalink
We briefly considered setting up a public bug tracking system, but it was deemed too distracting at this point (we have one in-house). The intense "grilling" is actually great within a team (some teams do role playing to achieve that). But it's obviously prone to misunderstandings without non-verbal contact, and even more so in a public forum.
I can somehow relate to outbursts of frustration. The other day I wanted to shove my desk out the window and smash the iMac to pieces. But that wasn't because Synfire or Windows. It was about Apple ;-)
Polyphony requires points ("velocity chords"), unless you know a way to stack multiple bars in a 3rd dimension. You can select any vertical and horizontal partial range, as with bars. Functionally, there isn't much of a difference besides the look.
Nobody else reporting doesn't mean everybody is happy. So after the little survey we had here, I'm relieved.
I agree with you that the UI could be more responsive on Windows. I'm primarily working on macOS and notice the difference between the platforms everytime I switch. I sense that most programs are slower on Windows but chalked that up to hardware specifics. I'm not happy with it yet, but I think it is absolutely workable, even with lots of containers and instruments. But what's fast enough for one person is slow for another.
If the performance is so bad that you can't even use a dozen or so containers, there is probably something else going wrong.
FYI: On Windows, Synfire needs to render all graphics to a bitmap first, then swaps it to the screen. Windows doesn't support transactional double buffering like macOS, which is needed to eliminate flicker. On HiDPI monitors, these bitmaps can be huge and they possibly slow down the "frame rate" much. I wouldn't be surprised if different PC hardware & drivers may lead to different user experiences.
That said, we'll have another look at the double buffering.
I should also note that after an exception ("crash") the double buffering is sometimes compromised and slows down significantly.
Wed, 2022-06-29 - 22:29 Permalink
That's hard to meet. I don't know many regular Windows programs this fast. According to my experience something around 50-80 ms is normal, depending on load. Of course, a 50 ms delay with typing code would drive me crazy. Switching tabs not so much. So I wonder which lag you think is most annoying and maybe tackle that with priority:
Let's make this a small survey. Which is worst, which is tolerable.
Mon, 2022-07-18 - 01:39 Permalink
@juergen: thank you.
No, I know, you told me that in the forum, so I always restart when that happens.
With Synfire we're talking 200ms to 1 second, especially e.g. with the Shift parameter (because it draws tons of stuff). I'm currently editing the video.
Regardless of numbers, which is difficult to estimate, with Synfire you feel the pain, while with FL Studio and Dorico the response is immediate. FL Studio responded instantly even on old machines and during playback.
With audio feedback disabled, you get the exact same issues, it's about drawing the GUI, not the rendering.
In any case, rendering should be done in another thread, and in general, in my opinion, as is done e.g. in Dorico, the sound should come later, the priority is on the editing. Editing should be immediate, otherwise the user wants to smash the PC. When you press play, Dorico takes its time (around 1 second) to calculate the resulting high resolution MIDI output; Synfire should do the same. But again, even with the sound off, the lag is still there, so it's the GUI.
Uh, none of it is tolerable, except maybe switching tabs. The GUI must be instantaneous unless you're going out of your way to e.g. open a Preferences dialog, switching a tab which loads other stuff, changing big things (like instruments, and general main settings about Synfire or the arrangement). Not when you're drawing a note or clicking a button. Even clicking the button for "shape" has a noticeable lag; even though this is the last of the problems, it contributes to the fact that the software feels sluggish.
My god.
Which however doesn't surprise me, because it's perfectly consistent with what I am experiencing. That's why I talked about "bad design choice". Because now you can't go back.
I'm talking exclusively visually, of course. Internally, they are obviously points. But visually they should be easily clickable, and vertical bars are the way to go, and are in fact "the standard" to edit velocities in software.
Wed, 2022-06-29 - 23:29 Permalink
Hey Scriabiner. Honestly my friend, I'm not having these problems, and it seems many others are not. But share that video and let's see what the culprit is. It's probably an easy fix, and will help any others in the same boat. In the meantime, cut Andre some slack please.
Wed, 2022-06-29 - 23:32 Permalink
I'm reporting problems, Cognitone will have their way of organizing their workload, it's not about me, uh.
That's very good to know, I suppose, because it's probably solvable.
Wed, 2022-06-29 - 23:48 Permalink
Most definitely, where's that video? :)
Thu, 2022-06-30 - 01:07 Permalink
This is what I have to deal with:
(https://www.dropbox.com/s/4aube9uru2d6l7o/Synfire%27s%20GUI.mp4?dl=0)
For proper watching, please consider downloading the file and watching full-screen, even though the quality is low; otherwise it's difficult to notice certain things, like the blue vertical bar of the selection (1 pixel).
Thu, 2022-06-30 - 11:22 Permalink
I can confirm everything. And to the question, what of this can be tolerated? I can tolerate everything. I have to. I don't have a choice.
Thu, 2022-06-30 - 12:28 Permalink
Thanks for the video. Some things are lagging worst than expected, others don't seem especially slow, but that's subjective. Your editing speed is certainly extreme. I get that it's to demonstrate the point.
What's your total screen resolution?
Again: Standards are fine but they don't apply here. We are NOT editing the velocities of notes. It's a standalone parameter that requires multiple velocities at the same point in time. And those are best visualized as "chords" of some sort. Not to mention five different modes of interpolation.
Interesting. On macOS it makes a big difference.
That's already the case. Something may be blocking the UI thread.
You seem to have never had a look into window servers. Double buffering is not a design decision, it's standard. Only that modern OS do this under the hood much more efficiently than programs can do it themselves. Windows is still stuck in the 1980's with graphics ops writing pixels to the device. With double buffering disabled, you see every single drawing action on screen, which is even worst than lag.
Fatalistic nonesense. Everything can be changed. We got the source code of language compilers, virtual machines and most libraries. Window's ancient graphics model however can't be changed. Maybe there's a workaround. Or a bug.
The button doesn't do anything except updating the visibility of tools.
If you expect Synfire to keep up with your keyboard's auto-repeat rate no matter which command, I'm afraid that won't happen before we eventually port to C++.
Thanks for the zoom and popup menu demo. Can't yet reproduce the popup issue, though. Menus open all correctly here even at the extreme margins of the screen.
Mon, 2022-07-18 - 01:37 Permalink
Please, don't try to find excuses: the user may work extremely slow, but the moment that he clicks, the software must respond instantly. Please install a demo (if you don't have the full version) of FL Studio, and play around with it. I'm suggesting it for real, I'm not kidding. Play around with it for a while, on Windows. Then, on the same system, start Synfire. Users are used to that kind of response time. And rightly so, it's 2022.
Don't use rendering as an excuse either, because in the moment of editing, FL Studio and Synfire are (or should be) the same: the complex harmonic rendering can be done later in a parallel thread and/or when activating playback.
If the user wants to use Synfire at 4K, maximized, it should be able to do it and he should have instant response time.
You don't understand, I'm not talking about how it's done internally: points at the same vertical positions are fine (they are needed!). I'm talking about visual editing. Please open Dorico and edit the velocities in the piano-roll, and notice that they are displayed as overlapping vertical bars. And exactly because of that, vertical bars are the perfect GUI solution to be able to select one specific bar, without also selecting the other one at the same vertical position, because, if they have different values, you simply click in the area of the bar that you want, leaving out the other bar; so, you get the same advantages of having points, but in addition you have a better method of letting the user select a specific bar without also selecting the other ones by mistake.
I mean, thinking about it, it doesn't matter that much: the real problem is that you cannot map a lower velocity to a higher note. That's the obvious dealbreaker. But that is related to voices, which is a very important missing feature, even though I appreciate the new editing mode where you can see the other instruments in the background, it's a good enough workaround, for now.
Yup, no difference here on Windows. Which makes sense, because the issue is GUI drawing, not the rendering of MIDI data.
Like... what, aside from the issues with the programming language (or whatever it is)?
Oh, ok. The way you said it, I thought it was something bad. Well, I don't know then. I mean, every other software in existence works fine on Windows, so I'm not sure where the problem lies, then.
Ok. What I meant is that you said that it would take re-programming the GUI in C++, but if there are other ways to go, that's good news!
Nope. Clicking a button sometimes takes like 200ms. So we're not talking a small-time. Aside from numbers, if you click a button and can notice, very clearly, that it takes time for it to change its image to "ON", it means that something is wrong with the drawing on the screen. The buttons are not the worse thing, of course, but they are a good indication, because there's certainly very few lines of code when you simply select a tool, so if the GUI doesn't respond instantly, it's a very good indication that something is wrong. Clicking a button shouldn't have more than 20ms delay: numbers aside, when it is noticeable, regardless of the number of ms, something is wrong.
Oh, ok...
That's bad news. If there's anything that I can do in regard to provide data and stuff, let me know. I can send, via email, specifications, etc.
It happens in all directions/axes.
Thu, 2022-06-30 - 18:12 Permalink
It seems velocity edits with the H-(yper) mode cannot be undone (they are seemingly not part of the undo-history). Not sure whether this is an issue new for the last version, but for me at least this is a serious issue.
Thu, 2022-06-30 - 21:38 Permalink
Another question: The "Hand Symbol" that now appears when dragging a selected symbol or phrase...is that really necessary? Not only does this look totally childish, it also disturbs editing. Because this hand obscures the point where you want to place the symbol. It should at least be possible to disable that.
Thu, 2022-06-30 - 22:11 Permalink
Isn't that a standard cursor for dragging? I've seen it in a lot of situations.
The most common is when you move a window with the keyboard: the mouse cursor changes to that, in basically every operating system.
Didn't have any problem with it, anyway the alternative could be this:
Thu, 2022-06-30 - 23:26 Permalink
I can confirm that I am experience lagging as well. For example, when selecting a figure or symbol (clicking with the mouse) I may have to wait for 2 secs or more until the selection is shown and effective. This is when editing some very short figures in a library with hardly any figures and on a very powerful WIn 10 machine that has been set up recently over the last view months (lots of music software installed, hardly anything else).
Context: I am used to do something pretty similar to Synfire's music prototyping in code, and compared to that having a GUI is faster, even if it is lagging that much, therefore I am accepting this. Anyway, waiting for > 2 secs after every mouse click does slow done editing (and considering that some clicks are not registered, and certain operations require multiple clicks, a simple operation like grouping two figures can easily take clearly more than 10 secs, and more if certain clicks are not registered correctly). Sometimes it is faster, and sometimes very slow, and I have not understood a pattern yet.
Sometimes a restart of the software can help, but because the rescanning of plugins always takes several minutes on my machine (seemingly in particular rescanning Melda Production plugins seems to take quite some time), I do not want to do restart Synfire too often either.
It might be that this lagging starts after certain operations, e.g., certain factory operations. I will try to keep an eye on whether I notice any pattern there, in case that could help.
Anyway, I don't want to sound too negative. I know that this is pre-release software, created by a small team that breaks new gound -- and I like its main approach. :-)
Mon, 2022-07-18 - 01:33 Permalink
Thank you for sharing your experience about this.
Synfire lags since V1 (at least on Windows).
No, I never loaded factories when doing the video, and I started with an empty project; factories work quite well for me, I have to say, for what I remember; the generation sure is superfast. It's about how much stuff the software has to draw on screen; which is why with the Shift parameter filled with rubato, which has a lot of green lines and points to draw, the software doesn't manage to draw in time. It may be more complex than that, of course.
[Redacted: useless long rant about the lag]
tl;dr: Yup, it has good unique features and potential, so we use it, but the GUI is a big issue and should really be fixed.
Fri, 2022-07-01 - 03:13 Permalink
@scriabiner If the problems you highlighted in your video occur for everyone on windows, I'm sure andre would have seen them in testing. If they had been there from day one in version 1 and were unresolvable, I doubt synfire would have been released on Windows. Back when synfire first released the majority of serious computer based musicians and djs used macs, so offering an unusable windows version could have affected total sales for only a small market increase.
I suspect the problem with the GUI lag is not affecting every windows user, so there has to be something different between those affected and those without issues. I suspect there is something in the smalltalk gui code/screen driver that isn't been well handled on certain graphics cards, hardware/firmware revision or driver versions. I've seen instances before where using recent drivers performed worse with older cards depending on what the application was trying to do as the latest drivers are designed to get the data to the gpu as fast as possible and that introduces delays when forced to resort to the cpu as the older hardware doesnt support some feature.
Unless andre can find some solution in the code or from the smalltalk developers, it might need some sort of survey to capture the detail specs of windows users, both those with and without issue. That would give andre and the smalltalk developers something to focus on, or if all else fails enable everyone affected to upgrade/downgrade firmware, drivers or hardware to a setup that works.
Fri, 2022-07-01 - 07:33 Permalink
> It might be that this lagging starts after certain operations, e.g., certain factory operations.
Last night, when I experienced this severe lag of > 2 secs per mouse click, restarting Synfire greatly reduced that to less than a second. So, there may always be a certain amount of lag at least on some platforms, but it seemingly can get far worse at times, and the latter may depend on certain operations.
Fri, 2022-07-01 - 07:43 Permalink
> FL Studio, Dorico...
I don't think it is fair to compare Synfire with applications like FL Studio, because Synfire targets a much smaller market with its unique features, and I applaud that. As a developer myself, I understand why they use Smalltalk for what they do, and I therefore accept that for this niche market the software has certain downsides like this lag.
For completeness, I think Dorico is a borderline case, also targeting a niche market (professional engravers, composers...) with their advanced notation capabilities, but with a big funder like Steinberg/Yamaha backing a much larger team than Synfire, they were allowed to spend several years just for laying down some great foundation for what they do. And even Dorico seems to recently try to increase its market share by spending serious development efforts on features not really relevant for their initial market (professional engravers).
Fri, 2022-07-01 - 10:47 Permalink
Switching to the German (or French) UI no longer works for me. Everything remains in English. Not that I use the German UI anymore, but I was curious what changed (maybe you got rid of the annoying term "Harmoniefolge" instead of Progression again?).
Fri, 2022-07-01 - 15:15 Permalink
@tanders @scriabiner are you using AMD or NVIDIA graphics cards?
Sat, 2022-10-01 - 20:57 Permalink
[redacted]
Fri, 2022-07-01 - 20:17 Permalink
> are you using AMD or NVIDIA graphics cards?
My Windows system shows it as a Nvidia GeForce GTX 1650. (My bill actually shows GeForce GTX 1650 WindForce, so I guess that only the graphics processor is by Nvidia, while the card is actually by Gigabyte.)
Sat, 2022-07-02 - 09:59 Permalink
Ah ok. So it's not a card thing.
I've checked by own installation, and for me, clicking on windows and tabs etc is all quite snappy.
I do get up to a 1 sec lag when dragging and moving multiple selections.