3 ms·

I don't work in the industry this OS is marketed towards. I do however have some experience in embedded development and synthesiser programming. Can someone mor

by ajxs 5y ago

I don't work in the industry this OS is marketed towards. I do however have some experience in embedded development and synthesiser programming. Can someone more familiar with the field answer a few questions for me? - The website says: "With Elk hardware companies can move away from dedicated chips and use general purpose ARM and x86 CPUs without any compromise in terms of latency, performance and scalability". Is this intended as a ready-made OS for hardware synthesisers, or as a way to host VSTs on consumer SoCs? - Assuming you're not targetting an obscure platform, or have a cumbersome toolchain, is writing a bare-metal executive the most difficult or expensive aspect of engineering a synthesiser? I've done some experiments breadboarding simple synthesisers with Arduino and STM development boards plus a 16-bit DAC. In my case the most challenging aspects weren't getting a real-time executive loop or handling I/O. Mind you, I didn't go as far as implementing a GUI. - Is real-time Linux not overkill for most synthesisers? From the outside looking in, it looks like it would add more overhead and complexity than solve problems. If your objective is just to host a VST, this might be a decent trade-off. Or maybe if you intend to use high-level languages for the GUI.

capableweb 5y ago
> - The website says: "With Elk hardware companies can move away from dedicated chips and use general purpose ARM and x86 CPUs without any compromise in terms of latency, performance and scalability". Is this intended as a ready-made OS for hardware synthesisers, or as a way to host VSTs on consumer SoCs? Seems like both and more. > is writing a bare-metal executive the most difficult or expensive aspect of engineering a synthesiser? Likely being a big part of the expense, yes. Obviously the hardware parts being a big chunk of it too, programming the software side of things are also expensive and sometimes makes the product receive less updates in the future because programmers who did understand the platform left the company. See Octatrack as an example, where the code is so complicated it's unlikely to see any bigger features released to it now as the original programmer left the company. Also, consider that many people have experience with general computing platforms while not having special expertise about particular chips, this solution on a general platform can help more people get started, learn more and maintain their own setups with skills that easily translate as well. > Is real-time Linux not overkill for most synthesisers? From the outside looking in, it looks like it would add more overhead and complexity than solve problems Probably, but probably not. Music making is more about having options available and use those in creative ways. Being able to use a general computing platform opens up more options than specially programmed OSes for particular instruments. Being able to revive old synths with new software would be wonderful.
scoutt 5y ago
> real-time executive loop or handling I/O I did some audio implementations on MCUs of all kind, and if I managed to pull out multitracked real-time mixed audio players under 4ms latency, I learn that the real problem here is RAM (other than computing power). Many audio effects requires lot of RAM. Think of how would you do a 5 seconds delay effect, or good quality pitch shifting (FT and inverse FT), reverb, echo, etc. Before you know it, 128KB of RAM is not enough any more. So now you are dreaming about 128MB of RAM (as minimum). If you want to process or output audio from/to network, USB or save the output into a file then you have to add that overhead to the equation. Before you notice it, you'll start looking at small processor like the i.MX28 or the like. Bare-metal BSPs for those processors are quite expensive in terms of code/time. You get what the manufacturer gives to you, and that is, a BSP for Linux.

by ajxs 5y ago

capableweb 5y ago

> - The website says: "With Elk hardware companies can move away from dedicated chips and use general purpose ARM and x86 CPUs without any compromise in terms of latency, performance and scalability". Is this intended as a ready-made OS for hardware synthesisers, or as a way to host VSTs on consumer SoCs? Seems like both and more. > is writing a bare-metal executive the most difficult or expensive aspect of engineering a synthesiser? Likely being a big part of the expense, yes. Obviously the hardware parts being a big chunk of it too, programming the software side of things are also expensive and sometimes makes the product receive less updates in the future because programmers who did understand the platform left the company. See Octatrack as an example, where the code is so complicated it's unlikely to see any bigger features released to it now as the original programmer left the company. Also, consider that many people have experience with general computing platforms while not having special expertise about particular chips, this solution on a general platform can help more people get started, learn more and maintain their own setups with skills that easily translate as well. > Is real-time Linux not overkill for most synthesisers? From the outside looking in, it looks like it would add more overhead and complexity than solve problems Probably, but probably not. Music making is more about having options available and use those in creative ways. Being able to use a general computing platform opens up more options than specially programmed OSes for particular instruments. Being able to revive old synths with new software would be wonderful.

scoutt 5y ago

> real-time executive loop or handling I/O I did some audio implementations on MCUs of all kind, and if I managed to pull out multitracked real-time mixed audio players under 4ms latency, I learn that the real problem here is RAM (other than computing power). Many audio effects requires lot of RAM. Think of how would you do a 5 seconds delay effect, or good quality pitch shifting (FT and inverse FT), reverb, echo, etc. Before you know it, 128KB of RAM is not enough any more. So now you are dreaming about 128MB of RAM (as minimum). If you want to process or output audio from/to network, USB or save the output into a file then you have to add that overhead to the equation. Before you notice it, you'll start looking at small processor like the i.MX28 or the like. Bare-metal BSPs for those processors are quite expensive in terms of code/time. You get what the manufacturer gives to you, and that is, a BSP for Linux.