Z-curious... anybody using Zrythm for actual production?

Support & discussion regarding DAWs and MIDI sequencers.

Moderators: MattKingUSA, khz

merlyn
Established Member
Posts: 1392
Joined: Thu Oct 11, 2018 4:13 pm
Has thanked: 168 times
Been thanked: 247 times

Re: Z-curious... anybody using Zrythm for actual production?

Post by merlyn »

I don't think it's JACK vs ALSA. It's modular vs monolithic. Linux offers us choice and we can do it either way.

Just my observation ... I think Ardour encourage using ALSA because it makes supporting Ardour easier. If Ardour recommended JACK there would be a huge amount of support going into getting JACK working ... then if the prospective user has survived that, then maybe they can get onto Ardour. x42 strikes me as a practical fellow. His explanation of why Ardour uses 32 bit float was "32 bit float is used for convenience, not fidelity". I would suggest the move towards ALSA is for similar reasons.

If you've seen someone use Ableton on Windows it may be clearer. A typical user boots up their machine and clicks the Ableton icon. That's as much of Windows as they see. I have a friend who wanted to get into MAX/MSP. "Hmmm", I thought, "sounds like a job for JACK", but no, it's possible to get MAX/MSP as a plugin for Ableton. How bonkers is that? Putting the mono into monolithic.

I use MuseScore and although some people may be excited by the thought of MuseScore as an lv2, I can't say that appeals to me.

But, as I said at the beginning, Linux offers choice and I don't think there is a right or wrong way of doing things. The right way is your way.
User avatar
bluzee
Established Member
Posts: 338
Joined: Mon Nov 30, 2020 11:43 pm
Has thanked: 18 times
Been thanked: 88 times

Re: Z-curious... anybody using Zrythm for actual production?

Post by bluzee »

If you've seen someone use Ableton on Windows it may be clearer. A typical user boots up their machine and clicks the Ableton icon. That's as much of Windows as they see.
Yes, I hear that. Of course they always forget to mention that they had to install the driver for their audio interface before that could happen. Installing JACK doesn't take any longer to do.

I also hear the developer explain why he doesn't want to reinvent the wheel and that makes more sense to me.
mene
Established Member
Posts: 4
Joined: Fri Jun 04, 2021 8:07 pm
Has thanked: 1 time
Been thanked: 1 time

Re: Z-curious... anybody using Zrythm for actual production?

Post by mene »

Love Zrythm, been following its development since about a year, i even made a small tutorial in Spanish to spread the love for it.

It loads every plugin i throw at it, the routing and automation is very cool and the interface is very simple and direct.

Hope nothing but the best for Alex and Zrythm.
alex stone
Established Member
Posts: 350
Joined: Fri Jun 06, 2008 7:39 am
Has thanked: 61 times
Been thanked: 53 times

Re: Z-curious... anybody using Zrythm for actual production?

Post by alex stone »

alextee wrote: Thu Mar 24, 2022 6:33 am ALSA is unusable as-is because it doesn't have an API usable by apps like DAWs. It's a very low level API intended for things like JACK and PipeWire. In the context of a DAW, you have to make it work by implementing it the way JACK does and there is no point doing that when JACK already does that. JACK is a thin layer on top of ALSA that makes ALSA usable for things like DAWs. The fact that it also allows connections is just a bonus. I still don't see any reason to use ALSA. There are absolutely no advantages in implementing an ALSA backend directly as a DAW. You get the exact same latencies with JACK. There are only disadvantages like having to maintain this hacky backend that is clearly not intended for audio applications, and people picking ALSA and saying Zrythm is broken because ALSA deadlocks or whatever (which is proof it's not an API suitable for audio apps). Do you actually get better latencies without JACK?

Also you are the first and only person who has ever wanted to use ALSA. Everyone else either uses JACK or PipeWire or doesn't know much about audio in which case PulseAudio will do the job, so there is not even any demand for an ALSA backend.

>Additionally ALSA MIDI is the superior choice for MIDI i/o and avoids some of the jitter issues associated with JACK MIDI.

How true is this? Have you discussed it with JACK devs? Is it a known issue? I have never heard of anyone experiencing device issues with JACK. It just works.
I have to jump in here, as both an AVL and Jack user for orchestral work.

In every distro i've tried and used, for big track count orchestral work, Alsamidi has been unstable, and regularly loses timing. In Jack, i have great timing, no matter how many tracks, plugins, standalones, etc, I have running. Nearly every statement of "Alsa midi is great" should come with a caveat of limited track count, and limited midi playback device numbers (number of plugins, other connected apps, etc). When I've commented that I've used over 750 tracks in a daw, it's been suggested I change my workflow, because NOBODY should be using that many tracks, if they're a "real" musician.

Jack midi, once I got my head around it, along with a kernel with good timing (1000), just kept, and keeps, rockin'. I've thrown 1200+ midi tracks at Jack, routing from multiple large linuxsampler server instances running my orchestral gig samples, just to see if I could break it. Nope.

Alsa midi couldn't cope with 40 midi tracks running a fairly simple orchestral project, starts to lose timing quickly, and in busy passages, slows to a crawl as it attempts to process a lot of midi throughput at once.

I challenge the notion Jackmidi has more jitters than Alsa midi, at least in large track counts. That's never been my experience, in all the time i've been using both.

It's important not to miss context in any discussion of Alsa V Jack, both midi and audio. Nearly every linux audio and midi user is more familiar with smaller track counts, usually under 40 tracks. A few years ago, I asked how many linux users were writing music with large sample libraries. There were three at that time, and 1 of them ran less than 100 tracks for his default template.
I suspect there are not many more than that now.

Please don't write off the importance of jack for handling large numbers of ports with sample accurate timing. It's essential, imho, for doing this, and Alsa doesn't come close.

I have persistently (and maybe annoyingly) pressed devs for years to make sure their particular masterpiece includes jack. Most get it, with a few giving valid reasons why they don't. (and a couple that won't).

Alsamidi introduces a limitation that those of us on the twilight zone end of using linux audio and midi run into quickly.

Jackmidi removes that limitation, and is (more or less) only limited by the capability of the hardware.

My two euros worth, for what it's worth,

Alex.
Kott
Established Member
Posts: 818
Joined: Thu Mar 21, 2013 12:55 am
Location: Vladivostok
Has thanked: 65 times
Been thanked: 122 times

Re: Z-curious... anybody using Zrythm for actual production?

Post by Kott »

I'm just curious about how you deal with 740 or 1200 midi tracks, and where (which DAW)?.
tseaver
Established Member
Posts: 398
Joined: Mon Mar 13, 2017 6:07 am
Has thanked: 11 times
Been thanked: 98 times

Re: Z-curious... anybody using Zrythm for actual production?

Post by tseaver »

@alex stone
Please don't write off the importance of jack for handling large numbers of ports with sample accurate timing. It's essential, imho, for doing this, and Alsa doesn't come close.
Thanks so much for substantiating the case for the higher-level, "over-engineered" JACK approach, even for users who which don't involve integration with an out-of-DAW audio app (my default use case has Guitarix running standalone for nearly any song).
Ubuntu, Mixbus32C; acoustic blues / country / jazz
j_e_f_f_g
Established Member
Posts: 2032
Joined: Fri Aug 10, 2012 10:48 pm
Been thanked: 357 times

Re: Z-curious... anybody using Zrythm for actual production?

Post by j_e_f_f_g »

alex stone wrote: I still don't see any reason to use ALSA. There are absolutely no advantages in implementing an ALSA backend directly as a DAW. You get the exact same latencies with JACK.
This is not true. First of all, JACK can never have "better", nor even equal, latency to ALSA. Why? Because JACK uses ALSA for its I/O. Therefore whatever latency jack causes must be added to any latency inherent in ALSA. That's basic physics and math.

What I've heard people argue is that whatever latency jack adds to alsa is "negligible". But in practice, it may very well be not so.

This is first time I've heard someone suggest that jack is lower latency. Let's kill this rumor before it gains any traction.
ALSA deadlocks
Huh? I write an audio app (BackupBand) that does audio I/O using either jack or ALSA's MMAP API. The later doesn't "deadlock" any moreso than jack. In fact, jack uses ALSA's MMAP API for audio I/O. So if JACK doesn't do something, then neither does ALSA.

Now, there are other ALSA API's (designed to be very easy to use) such as the block file I/O which deadlock, and are not designed for performance audio. But that's another story. A DAW wouldn't use that.
Alsamidi has been unstable, and regularly loses timing. In Jack, i have great timing
Again, you need to be specific. Alsa has 2 midi apis, Sequencer API, and rawmidi. rawmidi is as efficient as it gets for MIDI (and is what I use in BB). Sequencer API is not good, and I personally think it was a mistake to implement it. Unfortunately, just about every music app uses sequencer api, but that's because there are a lot of examples of its use. Music devs need to learn and use rawmidi API. (It's actually easier than seq api).
Jack midi keeps, rockin'.

Alsa midi couldn't cope
That's because you're undoubtably using sequencer api. In order to do that, your software synth has to run in a separate process than your daw. In order to use jack midi, your software synth has to run as a plugin in the DAW (same process). Of course you're going to get terrible performance with separate processes.

Plugins are more efficient than inter-process communication (IPC). That's one reason why jack audio I/O is less efficient than alsa MMAP. Jack is designed around IPC, whereas MMAP doesn't require that.

The limitations and performance issues you're talking about have everything to do with running your software synths as plugins versus in separate processes. Although ALSA's sequencer api inflicts IPC on midi (in the same way that jack inflicts ipc on audio), that doesn't mean that's your only option. Seq API should be your last resort.

Use a program that runs its software synths as plugins, and rawmidi to connect to your keyboard controller (like BB does), and it will yield as good a performance as you'll get.

Problem is -- too many linux devs know only how to use the slow IPC methods (jack audio, and sequencer api), and not the good methods (alsa MMAP, and alsa rawmidi with plugins).

Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.

alex stone
Established Member
Posts: 350
Joined: Fri Jun 06, 2008 7:39 am
Has thanked: 61 times
Been thanked: 53 times

Re: Z-curious... anybody using Zrythm for actual production?

Post by alex stone »

j_e_f_f_g wrote: Tue Apr 05, 2022 6:45 am
alex stone wrote: I still don't see any reason to use ALSA. There are absolutely no advantages in implementing an ALSA backend directly as a DAW. You get the exact same latencies with JACK.
This is not true. First of all, JACK can never have "better", nor even equal, latency to ALSA. Why? Because JACK uses ALSA for its I/O. Therefore whatever latency jack causes must be added to any latency inherent in ALSA. That's basic physics and math.

What I've heard people argue is that whatever latency jack adds to alsa is "negligible". But in practice, it may very well be not so.

This is first time I've heard someone suggest that jack is lower latency. Let's kill this rumor before it gains any traction.
ALSA deadlocks
Huh? I write an audio app (BackupBand) that does audio I/O using either jack or ALSA's MMAP API. The later doesn't "deadlock" any moreso than jack. In fact, jack uses ALSA's MMAP API for audio I/O. So if JACK doesn't do something, then neither does ALSA.

Now, there are other ALSA API's (designed to be very easy to use) such as the block file I/O which deadlock, and are not designed for performance audio. But that's another story. A DAW wouldn't use that.
Alsamidi has been unstable, and regularly loses timing. In Jack, i have great timing
Again, you need to be specific. Alsa has 2 midi apis, Sequencer API, and rawmidi. rawmidi is as efficient as it gets for MIDI (and is what I use in BB). Sequencer API is not good, and I personally think it was a mistake to implement it. Unfortunately, just about every music app uses sequencer api, but that's because there are a lot of examples of its use. Music devs need to learn and use rawmidi API. (It's actually easier than seq api).
Jack midi keeps, rockin'.

Alsa midi couldn't cope
That's because you're undoubtably using sequencer api. In order to do that, your software synth has to run in a separate process than your daw. In order to use jack midi, your software synth has to run as a plugin in the DAW (same process). Of course you're going to get terrible performance with separate processes.

Plugins are more efficient than inter-process communication (IPC). That's one reason why jack audio I/O is less efficient than alsa MMAP. Jack is designed around IPC, whereas MMAP doesn't require that.

The limitations and performance issues you're talking about have everything to do with running your software synths as plugins versus in separate processes. Although ALSA's sequencer api inflicts IPC on midi (in the same way that jack inflicts ipc on audio), that doesn't mean that's your only option. Seq API should be your last resort.

Use a program that runs its software synths as plugins, and rawmidi to connect to your keyboard controller (like BB does), and it will yield as good a performance as you'll get.

Problem is -- too many linux devs know only how to use the slow IPC methods (jack audio, and sequencer api), and not the good methods (alsa MMAP, and alsa rawmidi with plugins).
Jeff,

I don't use plugins for my sample libs. They're hosted on standalone linuxsampler server instances, and routed into a sequencer. I've tried running my large templates with plugins in a sequencer, with no success, as we don't have a sequencer in Linux that can handle 50,60,70 instrument plugins in a template, and not regularly crash from the effort, at least in my experience.. With Alsamidi in my setup the timing is frankly, drunk. I have had no problems using the same setup with Jackmidi.
I still don't see any reason to use ALSA. There are absolutely no advantages in implementing an ALSA backend directly as a DAW. You get the exact same latencies with JACK.
I didn't write this.
ALSA deadlocks.
Nor this.

Alex.
Last edited by alex stone on Tue Apr 05, 2022 10:53 am, edited 1 time in total.
alex stone
Established Member
Posts: 350
Joined: Fri Jun 06, 2008 7:39 am
Has thanked: 61 times
Been thanked: 53 times

Re: Z-curious... anybody using Zrythm for actual production?

Post by alex stone »

Kott wrote: Mon Apr 04, 2022 11:04 pm I'm just curious about how you deal with 740 or 1200 midi tracks, and where (which DAW)?.
I use 3 daws to varying degrees. Reaper for writing midi, Qtractor for tweaking, as it can run with the largest track counts, and occasionally Muse.

I rarely use plugins in the sequencers. My sample libraries run in two linuxsampler server instances with static templates, and I route to and from those instances into and out of a sequencer. Why? Because current linux based sequencers are good to excellent for smaller track counts, but can struggle with large to massive track counts. Qtractor and Reaper, in my user experience, are the most stable. I once built a 1000 track template for Qtractor, and it ran well.

Reaper has a limitation of midi ports available.
Qtractor is Alsamidi, but I can use a2jmidid to route into and out of Qtractor if i need to.
Muse has 1024 ports, although it gets wobbly over 150-160. I haven't tried Muse 4 yet, so I don't know if this large track count instability still exists.

I find myself defaulting to Reaper, as its midi tools are closest to a decent workflow.

I have tried Ardour, but couldn't get on with the midi workflow, but that's me. Others may have built large track count templates in Ardour and
have enjoyed themselves with the midi workflow as it is. I haven't tried Ardour for quite some time.
Alex.
j_e_f_f_g
Established Member
Posts: 2032
Joined: Fri Aug 10, 2012 10:48 pm
Been thanked: 357 times

Re: Z-curious... anybody using Zrythm for actual production?

Post by j_e_f_f_g »

I can use a2jmidid to route into and out of Qtractor
I knew there was something wrong with your observations about ALSA MIDI performance that had to be caused by an unrevealed culprit.

That culprit is now revealed, and it's the loathsome, performance-killing, piece of dung known as a2jmidi. No one should ever be subjected to something so odious as that.

When you have a2jmidi installed, you no longer have direct access to ALSA's Sequencer API. a2jmidi takes it over, and converts all the MIDI data to/from jack's internal midi format, ie, it converts the Seq messages to jackmidi. In other words, a2jmidi turns alsa midi into jackmidi with an extra layer of software processing. Of course, you're going to get worse performance with that. So when you say "Alsa midi performs worse than jackmidi.", you in fact are saying "a2jmidi really screws up midi performance.".

Welcome to the wonderful (in a terrifying way) world of "Linux audio bridges". These things are all total, performance-robbing garbage. You need to treat them like trojan programs. Wipe them off your system.

Why do they exist? Because lazy, incompetent programmers keep writing software that can't use alsa MMAP audio, and alsa rawmidi. So folks keep making crap that takes alsa MMAP and rawmidi (or Seq API), and converts it to the only s*** these programmers know how to support -- jack audio and jack midi.

If I were you, I'd clean out my system, and then look for software that directly supports alsa. Every copy of linux comes with working alsa MMAP audio and rawmidi. It's part of the OS. Anything else is crap that squats on top of those two things and may work, or just as likely leave a big stinking pile of bloat.

Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.

alex stone
Established Member
Posts: 350
Joined: Fri Jun 06, 2008 7:39 am
Has thanked: 61 times
Been thanked: 53 times

Re: Z-curious... anybody using Zrythm for actual production?

Post by alex stone »

j_e_f_f_g wrote: Tue Apr 05, 2022 6:29 pm
I can use a2jmidid to route into and out of Qtractor
I knew there was something wrong with your observations about ALSA MIDI performance that had to be caused by an unrevealed culprit.

That culprit is now revealed, and it's the loathsome, performance-killing, piece of dung known as a2jmidi. No one should ever be subjected to something so odious as that.

When you have a2jmidi installed, you no longer have direct access to ALSA's Sequencer API. a2jmidi takes it over, and converts all the MIDI data to/from jack's internal midi format, ie, it converts the Seq messages to jackmidi. In other words, a2jmidi turns alsa midi into jackmidi with an extra layer of software processing. Of course, you're going to get worse performance with that. So when you say "Alsa midi performs worse than jackmidi.", you in fact are saying "a2jmidi really screws up midi performance.".

Welcome to the wonderful (in a terrifying way) world of "Linux audio bridges". These things are all total, performance-robbing garbage. You need to treat them like trojan programs. Wipe them off your system.

Why do they exist? Because lazy, incompetent programmers keep writing software that can't use alsa MMAP audio, and alsa rawmidi. So folks keep making crap that takes alsa MMAP and rawmidi (or Seq API), and converts it to the only s*** these programmers know how to support -- jack audio and jack midi.

If I were you, I'd clean out my system, and then look for software that directly supports alsa. Every copy of linux comes with working alsa MMAP audio and rawmidi. It's part of the OS. Anything else is crap that squats on top of those two things and may work, or just as likely leave a big stinking pile of bloat.
I've only used a2j with Qtractor as it doesn't support jackmidi natively, as i wrote.
glowrak guy
Established Member
Posts: 2315
Joined: Sat Jun 21, 2014 8:37 pm
Been thanked: 251 times

Re: Z-curious... anybody using Zrythm for actual production?

Post by glowrak guy »

j_e_f_f_g wrote: Tue Apr 05, 2022 6:45 am Problem is -- too many linux devs know only how to use the slow IPC methods (jack audio, and sequencer api), and not the good methods (alsa MMAP, and alsa rawmidi with plugins).
Maybe you could create some tutorials for linux devs?
Cheers
j_e_f_f_g
Established Member
Posts: 2032
Joined: Fri Aug 10, 2012 10:48 pm
Been thanked: 357 times

Re: Z-curious... anybody using Zrythm for actual production?

Post by j_e_f_f_g »

glowrak guy wrote: Maybe you could create some tutorials for linux devs?
I posted a tutorial years ago here on using rawmidi API, with example code. Here it is again. Parts of the tutorial were not finished, as I got too busy. But the rawmidi stuff is mostly there.
Attachments
alsa_midi_api.zip
(87.14 KiB) Downloaded 78 times

Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.

Kott
Established Member
Posts: 818
Joined: Thu Mar 21, 2013 12:55 am
Location: Vladivostok
Has thanked: 65 times
Been thanked: 122 times

Re: Z-curious... anybody using Zrythm for actual production?

Post by Kott »

alex stone wrote: Tue Apr 05, 2022 10:50 am
Kott wrote: Mon Apr 04, 2022 11:04 pm I'm just curious about how you deal with 740 or 1200 midi tracks, and where (which DAW)?.
I use 3 daws to varying degrees. Reaper for writing midi, Qtractor for tweaking, as it can run with the largest track counts, and occasionally Muse.

I rarely use plugins in the sequencers. My sample libraries run in two linuxsampler server instances with static templates, and I route to and from those instances into and out of a sequencer. Why? Because current linux based sequencers are good to excellent for smaller track counts, but can struggle with large to massive track counts. Qtractor and Reaper, in my user experience, are the most stable. I once built a 1000 track template for Qtractor, and it ran well.

Reaper has a limitation of midi ports available.
Qtractor is Alsamidi, but I can use a2jmidid to route into and out of Qtractor if i need to.
Muse has 1024 ports, although it gets wobbly over 150-160. I haven't tried Muse 4 yet, so I don't know if this large track count instability still exists.

I find myself defaulting to Reaper, as its midi tools are closest to a decent workflow.

I have tried Ardour, but couldn't get on with the midi workflow, but that's me. Others may have built large track count templates in Ardour and
have enjoyed themselves with the midi workflow as it is. I haven't tried Ardour for quite some time.
Alex.
looks impressive, I'm still try to understand the purpose of hundreds midi tracks
j_e_f_f_g
Established Member
Posts: 2032
Joined: Fri Aug 10, 2012 10:48 pm
Been thanked: 357 times

Re: Z-curious... anybody using Zrythm for actual production?

Post by j_e_f_f_g »

Kott wrote: the purpose of hundreds midi tracks
I'm gonna guess what he's doing. I suspect that he's creating an orchestra entirely out of solo instrument VSTs. For example, let's say he wants a 20 piece violin section. Instead of loading one VST that contains a 20 piece string section, he's loading up 20 solo violin VSTs and having them simultaneously play the same midi track. That's his "violin section". And of course that's just one articulation. He also needs 20 solo violin VSTs playing Pizzicato. And 20 more for Tremulo, Etc.

And that's just the violin section. Imagine doing this with every orchestral section. There's where the hundreds of VSTs come in.

And I'm gonna take another guess that he's doing this because he thinks it will more realistically simulate an actual orchestra. But that's a misconception. First of all, if those 20 violins are all the same VST (instead of entirely different sample sets), he could end up creating a sound that is less realistic than a VST of a section of actually different violins. Secondly, as a classical music major in college, I had to learn arranging, and what I learned is that the important thing is not your instrumentation, but rather how you work with it. For example, if it's easier to add nuances like legato bowing, volume swells, etc using a VST of a violin section than it is to do the same thing with 20 separate solo violin VSTs, the latter could end up sounding quite unrealistic.

But the most important thing is; if I've guessed correctly about what it is Alex is doing, then his friends and family need to stage an intervention pronto.

Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.

Post Reply