Re: [Rosegarden-user] Any plans to support LV2 plug-ins?
Well, I've made a couple of attempts to use Ardour. It's a very powerful tool of audio engineers. For someone more ordinary, like me, who doesn't do much with recorded audio, it's way beyond me. Rosegarden does the MIDI and scoring I need. For a final, complete, beautiful score, I use MuseScore. On 2/19/23 20:06, Mike Broughton wrote: Not to steal a thread, but rather than rosegarden supporting all these formats, have you considered rosegarden becoming a plugin so that you can use it in say, ardour. Keep rosegarden a special notation piece, and let others worry about the extra fluff. Sorry if this has been considered before. Mike On 18 Feb 2023 11:06, Lorenzo Sutton wrote: On 18/02/2023 04:57, david wrote: > I was wondering about that. With RG already supporting ALSA MIDI, what's > the showstopper with similarly supporting JACK MIDI? Actually, I feel that the uncertainty Pipewire it bringing to the Linux Pro Audio world (see discussions on LAD for example), and the risk JACK is in the longer term, I feel link bumping up LV2 support in Rosegarden. Then JACK MIDI as Carla for example only supports JACK MIDI. Unfortunately it seems that the modular approach of 'an app does something well' philosophy is at risk if JACK is at risk... Just a quick guts feeling here, and I totally understand the kind of endeavor LV2 would be... In an ideal world I'd be happy for Rosegarden to do 'just' MIDI (maybe JACK Midi), and then have external software do the plugins. I've written a lot about e.g. rendering with jack freewheel etc. but I think the trend now is to go on Linux to the one-DAW-does-it-all probably because of commercial software like Bitwig or Reaper now available for Linux and having that approach and Ardour trying to follow on that (albeit IMHO still lacking to much in the MIDI department). Enough rambling there, just my 2 cents :-) Lorenzo > > Let us continue to ignore those that might pipe up, "Why support either > of those when you could just support Pipewire instead?" ;) > > On 2/17/23 17:38, Ted Felix wrote: >> No plans. I would love to do it, though. Along with JACK MIDI. >> Need to find some more time. >> >> Ted. >> >> On 2/17/23 10:05 PM, david wrote: >>> Inspired by a question from Paul Davus on the Linux-Users-Audio list, >>> when he replied to my request that Yoshimi add DSSI support: "Why do >>> you want DSSI instead of LV2?" >>> >>> I replied that Rosegarden doesn't support LV2. >>> >>> I see this feature request: >>> >>> https://sourceforge.net/p/rosegarden/feature-requests/462/ >>> >>> The last item on that list quotes someone else saying: >>> Rosegarden does not need native LV2. Carla should have all the plugin support needed for a project. We don't need several programs all doing the same thing. >>> Only issue with that for me is, I went to my Debian 11 repository - >>> and Carla isn't there. It's not available in Debian. Apparently only >>> through KXStudio repository? >>> >>> I would still prefer RG having LV2 support built-in, instead of >>> having to install yet another program. >>> >>> Ideas? > -- David W. Jones gn...@hawaii.rr.com authenticity, honesty, community http://dancingtreefrog.com "My password is the last 8 digits of π." ___ Rosegarden-user mailing list Rosegarden-user@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-user
Re: [Rosegarden-user] Any plans to support LV2 plug-ins?
Not to steal a thread, but rather than rosegarden supporting all these formats, have you considered rosegarden becoming a plugin so that you can use it in say, ardour. Keep rosegarden a special notation piece, and let others worry about the extra fluff.Sorry if this has been considered before.MikeOn 18 Feb 2023 11:06, Lorenzo Sutton wrote:On 18/02/2023 04:57, david wrote: > I was wondering about that. With RG already supporting ALSA MIDI, what's > the showstopper with similarly supporting JACK MIDI? Actually, I feel that the uncertainty Pipewire it bringing to the Linux Pro Audio world (see discussions on LAD for example), and the risk JACK is in the longer term, I feel link bumping up LV2 support in Rosegarden. Then JACK MIDI as Carla for example only supports JACK MIDI. Unfortunately it seems that the modular approach of 'an app does something well' philosophy is at risk if JACK is at risk... Just a quick guts feeling here, and I totally understand the kind of endeavor LV2 would be... In an ideal world I'd be happy for Rosegarden to do 'just' MIDI (maybe JACK Midi), and then have external software do the plugins. I've written a lot about e.g. rendering with jack freewheel etc. but I think the trend now is to go on Linux to the one-DAW-does-it-all probably because of commercial software like Bitwig or Reaper now available for Linux and having that approach and Ardour trying to follow on that (albeit IMHO still lacking to much in the MIDI department). Enough rambling there, just my 2 cents :-) Lorenzo > > Let us continue to ignore those that might pipe up, "Why support either > of those when you could just support Pipewire instead?" ;) > > On 2/17/23 17:38, Ted Felix wrote: >> No plans. I would love to do it, though. Along with JACK MIDI. >> Need to find some more time. >> >> Ted. >> >> On 2/17/23 10:05 PM, david wrote: >>> Inspired by a question from Paul Davus on the Linux-Users-Audio list, >>> when he replied to my request that Yoshimi add DSSI support: "Why do >>> you want DSSI instead of LV2?" >>> >>> I replied that Rosegarden doesn't support LV2. >>> >>> I see this feature request: >>> >>> https://sourceforge.net/p/rosegarden/feature-requests/462/ >>> >>> The last item on that list quotes someone else saying: >>> Rosegarden does not need native LV2. Carla should have all the plugin support needed for a project. We don't need several programs all doing the same thing. >>> Only issue with that for me is, I went to my Debian 11 repository - >>> and Carla isn't there. It's not available in Debian. Apparently only >>> through KXStudio repository? >>> >>> I would still prefer RG having LV2 support built-in, instead of >>> having to install yet another program. >>> >>> Ideas? > ___ Rosegarden-user mailing list Rosegarden-user@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-user ___ Rosegarden-user mailing list Rosegarden-user@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-user
Re: [Rosegarden-user] Transport problem
I haven't noticed any problems but the current standard kernel in Fedora 36 has: CONFIG_PREEMPT_DYNAMIC=y CONFIG_PREEMPT_VOLUNTARY=y in /boot/config-$(uname -r) does this need to be overridden in /etc/default/grub or in a kernel rebuild ? On 19/02/2023 5:19 pm, Ted Felix wrote: Will, can you go through this first draft series of steps on the problematic box and let me know if it finds the issue? Thanks. Boot into the problematic kernel. Confirm that it is a preemptible kernel. $ grep -i config_preempt= /boot/config-$(uname -r) CONFIG_PREEMPT=y If you don't see "CONFIG_PREEMPT=y" then you need to install a preemptible kernel. Check the grub configuration to make sure nothing is specified on the kernel command line related to preemption. $ grep -i preempt /etc/default/grub You should either see nothing or "preempt=full" along with possibly other options. Anything else might mean trouble and requires a change to your grub config. Check for voluntary preemption. (Not sure how this fits into everything, but it might cause problems and need some further investigation.) $ grep -i preempt_voluntary /boot/config-$(uname -r) # CONFIG_PREEMPT_VOLUNTARY is not set Ted. On 2/19/23 11:48 AM, Ted Felix wrote: On second thought... We've been here before. From my Linux MIDI Guide: Note: There are variations on PREEMPT that are less than ideal. "DYNAMIC_PREEMPT" allows PREEMPT to be turned on and off in the kernel command line options (preempt=full). You'll need to check your GRUB configuration to make sure this is either set to "preempt=full" or not set at all (the default is "full") in "GRUB_CMDLINE_LINUX_DEFAULT=". You can check the setting after boot with "sudo dmesg | grep preempt". There is also PREEMPT_VOLUNTARY which is somewhere between "NONE" and "PREEMPT". You'll want to avoid this as audio requires the best possible real-time performance. I should probably make that a bit more prominent now that we are running into it for real. Like move it up to the "things you'll need" section at the very top. Ted. On 2/19/23 8:52 AM, Ted Felix wrote: We rely completely on ALSA for timer stuff. The key routine for setting the timer in RG is: AlsaDriver::setCurrentTimer() Unless there is a bug in there (which there may very well be, the ALSA documentation is incomplete and in many cases incorrect), the problems tend to be due to bugs in ALSA or the kernel. They usually get sorted over time by the ALSA folks. If they notice them. This one seems like an interesting combination of requirements to reproduce and thus might fly under their radar. I recommend building the latest kernel and seeing if that fixes the issue. My three-year-old Debian/Ubuntu oriented notes are here if you need: http://www.tedfelix.com/linux/kernel-build.html In general, it's really easy to do. If it's still there, a bug report for the ALSA folks seems like the way to go. They can help find the issue in ALSA, or even in Rosegarden if that's where the problem is. Ted. On 2/11/23 4:42 AM, Will Godfrey wrote: Recently I found Rosegarden was losing the timer source, and the transport was freezing - sometimes for nearly a second after which it would send a bunch of notes, then carry on as normal. It was some time before I realised it only happened on my Ryzen 5 machine (the one I use for music) and not on my office Intel one. I hadn't made any changes to the system and got sidetracked into thinking maybe I'd somehow managed to get infected with some malware. However I eventually remembered I'd done a normal devuan update. The only significant change was the Linux kernel V5.10 to V 6.1. Rolling that back cured the problem. Asking some questions on-line identified the problem. First off, I use the RT-Preemt kernel - the 'normal' one doesn't have the issue at all. Secondly, the Ryzen has the AMD equivalent of hyper-threading, my older Intel doesn't. Finally, since Linux V5.12 the scheduler has been modified to allow dynamic preemption. Disabling this in the BIOS cures the problem, albeit with a very small loss of performance. I wonder if there should be another look at how Rosegarden does it's timing. I did try to set the timing source to the audio hardware. It seemed to recognise it, but actually totally ignored it. Saving and reloading showed no time source at all, yet still ran as if it was on System Timer. ___ Rosegarden-user mailing list Rosegarden-user@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-user ___ Rosegarden-user mailing list Rosegarden-user@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-user ___
Re: [Rosegarden-user] Transport problem
Will, can you go through this first draft series of steps on the problematic box and let me know if it finds the issue? Thanks. Boot into the problematic kernel. Confirm that it is a preemptible kernel. $ grep -i config_preempt= /boot/config-$(uname -r) CONFIG_PREEMPT=y If you don't see "CONFIG_PREEMPT=y" then you need to install a preemptible kernel. Check the grub configuration to make sure nothing is specified on the kernel command line related to preemption. $ grep -i preempt /etc/default/grub You should either see nothing or "preempt=full" along with possibly other options. Anything else might mean trouble and requires a change to your grub config. Check for voluntary preemption. (Not sure how this fits into everything, but it might cause problems and need some further investigation.) $ grep -i preempt_voluntary /boot/config-$(uname -r) # CONFIG_PREEMPT_VOLUNTARY is not set Ted. On 2/19/23 11:48 AM, Ted Felix wrote: On second thought... We've been here before. From my Linux MIDI Guide: Note: There are variations on PREEMPT that are less than ideal. "DYNAMIC_PREEMPT" allows PREEMPT to be turned on and off in the kernel command line options (preempt=full). You'll need to check your GRUB configuration to make sure this is either set to "preempt=full" or not set at all (the default is "full") in "GRUB_CMDLINE_LINUX_DEFAULT=". You can check the setting after boot with "sudo dmesg | grep preempt". There is also PREEMPT_VOLUNTARY which is somewhere between "NONE" and "PREEMPT". You'll want to avoid this as audio requires the best possible real-time performance. I should probably make that a bit more prominent now that we are running into it for real. Like move it up to the "things you'll need" section at the very top. Ted. On 2/19/23 8:52 AM, Ted Felix wrote: We rely completely on ALSA for timer stuff. The key routine for setting the timer in RG is: AlsaDriver::setCurrentTimer() Unless there is a bug in there (which there may very well be, the ALSA documentation is incomplete and in many cases incorrect), the problems tend to be due to bugs in ALSA or the kernel. They usually get sorted over time by the ALSA folks. If they notice them. This one seems like an interesting combination of requirements to reproduce and thus might fly under their radar. I recommend building the latest kernel and seeing if that fixes the issue. My three-year-old Debian/Ubuntu oriented notes are here if you need: http://www.tedfelix.com/linux/kernel-build.html In general, it's really easy to do. If it's still there, a bug report for the ALSA folks seems like the way to go. They can help find the issue in ALSA, or even in Rosegarden if that's where the problem is. Ted. On 2/11/23 4:42 AM, Will Godfrey wrote: Recently I found Rosegarden was losing the timer source, and the transport was freezing - sometimes for nearly a second after which it would send a bunch of notes, then carry on as normal. It was some time before I realised it only happened on my Ryzen 5 machine (the one I use for music) and not on my office Intel one. I hadn't made any changes to the system and got sidetracked into thinking maybe I'd somehow managed to get infected with some malware. However I eventually remembered I'd done a normal devuan update. The only significant change was the Linux kernel V5.10 to V 6.1. Rolling that back cured the problem. Asking some questions on-line identified the problem. First off, I use the RT-Preemt kernel - the 'normal' one doesn't have the issue at all. Secondly, the Ryzen has the AMD equivalent of hyper-threading, my older Intel doesn't. Finally, since Linux V5.12 the scheduler has been modified to allow dynamic preemption. Disabling this in the BIOS cures the problem, albeit with a very small loss of performance. I wonder if there should be another look at how Rosegarden does it's timing. I did try to set the timing source to the audio hardware. It seemed to recognise it, but actually totally ignored it. Saving and reloading showed no time source at all, yet still ran as if it was on System Timer. ___ Rosegarden-user mailing list Rosegarden-user@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-user ___ Rosegarden-user mailing list Rosegarden-user@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-user ___ Rosegarden-user mailing list Rosegarden-user@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-user
Re: [Rosegarden-user] Transport problem
On second thought... We've been here before. From my Linux MIDI Guide: Note: There are variations on PREEMPT that are less than ideal. "DYNAMIC_PREEMPT" allows PREEMPT to be turned on and off in the kernel command line options (preempt=full). You'll need to check your GRUB configuration to make sure this is either set to "preempt=full" or not set at all (the default is "full") in "GRUB_CMDLINE_LINUX_DEFAULT=". You can check the setting after boot with "sudo dmesg | grep preempt". There is also PREEMPT_VOLUNTARY which is somewhere between "NONE" and "PREEMPT". You'll want to avoid this as audio requires the best possible real-time performance. I should probably make that a bit more prominent now that we are running into it for real. Like move it up to the "things you'll need" section at the very top. Ted. On 2/19/23 8:52 AM, Ted Felix wrote: We rely completely on ALSA for timer stuff. The key routine for setting the timer in RG is: AlsaDriver::setCurrentTimer() Unless there is a bug in there (which there may very well be, the ALSA documentation is incomplete and in many cases incorrect), the problems tend to be due to bugs in ALSA or the kernel. They usually get sorted over time by the ALSA folks. If they notice them. This one seems like an interesting combination of requirements to reproduce and thus might fly under their radar. I recommend building the latest kernel and seeing if that fixes the issue. My three-year-old Debian/Ubuntu oriented notes are here if you need: http://www.tedfelix.com/linux/kernel-build.html In general, it's really easy to do. If it's still there, a bug report for the ALSA folks seems like the way to go. They can help find the issue in ALSA, or even in Rosegarden if that's where the problem is. Ted. On 2/11/23 4:42 AM, Will Godfrey wrote: Recently I found Rosegarden was losing the timer source, and the transport was freezing - sometimes for nearly a second after which it would send a bunch of notes, then carry on as normal. It was some time before I realised it only happened on my Ryzen 5 machine (the one I use for music) and not on my office Intel one. I hadn't made any changes to the system and got sidetracked into thinking maybe I'd somehow managed to get infected with some malware. However I eventually remembered I'd done a normal devuan update. The only significant change was the Linux kernel V5.10 to V 6.1. Rolling that back cured the problem. Asking some questions on-line identified the problem. First off, I use the RT-Preemt kernel - the 'normal' one doesn't have the issue at all. Secondly, the Ryzen has the AMD equivalent of hyper-threading, my older Intel doesn't. Finally, since Linux V5.12 the scheduler has been modified to allow dynamic preemption. Disabling this in the BIOS cures the problem, albeit with a very small loss of performance. I wonder if there should be another look at how Rosegarden does it's timing. I did try to set the timing source to the audio hardware. It seemed to recognise it, but actually totally ignored it. Saving and reloading showed no time source at all, yet still ran as if it was on System Timer. ___ Rosegarden-user mailing list Rosegarden-user@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-user ___ Rosegarden-user mailing list Rosegarden-user@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-user
Re: [Rosegarden-user] Transport problem
Hello, > the ALSA documentation is incomplete and in many cases incorrect Do you happen to remember off hand which parts are incorrect? I think we should report them to the ALSA project. - PM On Sun, 19 Feb 2023, 13:53 Ted Felix, wrote: >We rely completely on ALSA for timer stuff. The key routine for > setting the timer in RG is: > > AlsaDriver::setCurrentTimer() > >Unless there is a bug in there (which there may very well be, the > ALSA documentation is incomplete and in many cases incorrect), the > problems tend to be due to bugs in ALSA or the kernel. They usually get > sorted over time by the ALSA folks. If they notice them. This one > seems like an interesting combination of requirements to reproduce and > thus might fly under their radar. > >I recommend building the latest kernel and seeing if that fixes the > issue. My three-year-old Debian/Ubuntu oriented notes are here if you > need: > > http://www.tedfelix.com/linux/kernel-build.html > >In general, it's really easy to do. > >If it's still there, a bug report for the ALSA folks seems like the > way to go. They can help find the issue in ALSA, or even in Rosegarden > if that's where the problem is. > > Ted. > > On 2/11/23 4:42 AM, Will Godfrey wrote: > > Recently I found Rosegarden was losing the timer source, and the > transport was > > freezing - sometimes for nearly a second after which it would send a > bunch of > > notes, then carry on as normal. > > > > It was some time before I realised it only happened on my Ryzen 5 > machine (the > > one I use for music) and not on my office Intel one. I hadn't made any > changes > > to the system and got sidetracked into thinking maybe I'd somehow > managed to > > get infected with some malware. However I eventually remembered I'd done > a > > normal devuan update. The only significant change was the Linux kernel > V5.10 to > > V 6.1. Rolling that back cured the problem. > > > > Asking some questions on-line identified the problem. > > > > First off, I use the RT-Preemt kernel - the 'normal' one doesn't have > the issue > > at all. > > > > Secondly, the Ryzen has the AMD equivalent of hyper-threading, my older > Intel > > doesn't. > > > > Finally, since Linux V5.12 the scheduler has been modified to allow > dynamic > > preemption. Disabling this in the BIOS cures the problem, albeit with a > very > > small loss of performance. > > > > I wonder if there should be another look at how Rosegarden does it's > timing. I > > did try to set the timing source to the audio hardware. It seemed to > recognise > > it, but actually totally ignored it. Saving and reloading showed no time > source > > at all, yet still ran as if it was on System Timer. > > > > > ___ > Rosegarden-user mailing list > Rosegarden-user@lists.sourceforge.net - use the link below to unsubscribe > https://lists.sourceforge.net/lists/listinfo/rosegarden-user > ___ Rosegarden-user mailing list Rosegarden-user@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-user
Re: [Rosegarden-user] Transport problem
We rely completely on ALSA for timer stuff. The key routine for setting the timer in RG is: AlsaDriver::setCurrentTimer() Unless there is a bug in there (which there may very well be, the ALSA documentation is incomplete and in many cases incorrect), the problems tend to be due to bugs in ALSA or the kernel. They usually get sorted over time by the ALSA folks. If they notice them. This one seems like an interesting combination of requirements to reproduce and thus might fly under their radar. I recommend building the latest kernel and seeing if that fixes the issue. My three-year-old Debian/Ubuntu oriented notes are here if you need: http://www.tedfelix.com/linux/kernel-build.html In general, it's really easy to do. If it's still there, a bug report for the ALSA folks seems like the way to go. They can help find the issue in ALSA, or even in Rosegarden if that's where the problem is. Ted. On 2/11/23 4:42 AM, Will Godfrey wrote: Recently I found Rosegarden was losing the timer source, and the transport was freezing - sometimes for nearly a second after which it would send a bunch of notes, then carry on as normal. It was some time before I realised it only happened on my Ryzen 5 machine (the one I use for music) and not on my office Intel one. I hadn't made any changes to the system and got sidetracked into thinking maybe I'd somehow managed to get infected with some malware. However I eventually remembered I'd done a normal devuan update. The only significant change was the Linux kernel V5.10 to V 6.1. Rolling that back cured the problem. Asking some questions on-line identified the problem. First off, I use the RT-Preemt kernel - the 'normal' one doesn't have the issue at all. Secondly, the Ryzen has the AMD equivalent of hyper-threading, my older Intel doesn't. Finally, since Linux V5.12 the scheduler has been modified to allow dynamic preemption. Disabling this in the BIOS cures the problem, albeit with a very small loss of performance. I wonder if there should be another look at how Rosegarden does it's timing. I did try to set the timing source to the audio hardware. It seemed to recognise it, but actually totally ignored it. Saving and reloading showed no time source at all, yet still ran as if it was on System Timer. ___ Rosegarden-user mailing list Rosegarden-user@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-user
