Now, intuitively the sequencer is quite complex thing, since it encompasses:
- MIDI events and processes on them
- playing back audio samples and processes on audio samples
How can one study such thing?
Start building a thing. Run into problems. Think hard about it. Look for a framework that might fit the bill. Start over building a thing with the framework. Run into problems again. Have a better and much simpler idea on how to do this now that you've gained some experience. Start over again with your new concept of the simplest way to build a thing. Run into roadblocks again and discover the limitations of your elegant simplistic approach. Start over again, this time with a much more complex but flexible and rigorous concept, which is impossible to explain to anyone. Get annoyed with the complex structure you've built around yourself. Swing back and forth between complex and simplistic concepts for ~20 years. Then finally build something very messy out of bits and pieces from the last 20 years that at least works and somehow resembles a product.
But I think we want the audio I/O to be as fast as possible. It's just that because of the GUI with this there's also I/O from the data to the UI. And since this is a low-latency app, then I am not sure if some Java Swing design pattern is relevant. In Swing etc. we'd say that the GUI is almost never a cause for a bottleneck.hugoderwolf wrote: ↑Wed Mar 06, 2024 9:23 amIf your goal is to build something complex like a DAW with "least amount of instructions", you're entering the world of pain: the less code you're ready to write to express something complex, the more rigid, inflexible and tightly coupled it has to be.
But it does because Swing etc. frameworks already do the decoupling. And they say that for 60 FPS or whatever that GUI code and the framework is almost never the cause of slugginess.hugoderwolf wrote: ↑Wed Mar 06, 2024 9:39 am Nothing to do with Java Swing. It' the core of what programming actually is.
My advice is to start building something rather than thinking too deeply about all of this beforehand. Build something, and you'll understand.
No but this has been explored for 10s of years already, so some people know already. No need to reinvent the wheel here. Just cannot find existing source code to make it simple to study. If just REAPER was open source.hugoderwolf wrote: ↑Wed Mar 06, 2024 11:17 am This is all very blurry, and I honestly don't understand what you are trying to say or ask, and what problem you are trying to solve. Can you be more specific, please? What do you want to build? Have you tried building it in practice yet? What challenges have you encountered? What do you want to talk about? UI? Drawing (not the same as UI)? MIDI? Realtime Audio? DSP? General software architecture? Those are all very different topics, and you need to focus on one at a time in order to understand how all of it fits together in practice.
https://www.theseus.fi/bitstream/handle ... sequence=2Another problem is heavy UI fragments. The EffectFragment requires a lot of UI
elements: global views, switches, sliders and dynamic text fields. Navigating to
this fragment could be a bit slow on old devices. This problem could be resolved
by rebuilding the EffectFragment in a more modular way. For example using the
RecyclerView class could be the solution to this problem.
1. These are two different topics (sequencing & sample streaming) which are not related while you do make them related. Stop doing that.soundmodel wrote: ↑Wed Mar 06, 2024 8:30 am I tried to search for source code for the host sequencer part, and while I can find some that work, I was puzzled by seeing some implementations seeming quite slow (even if they're in C) while also reading some papers that discussed e.g. how from-disk reading is done efficiently for samples.
© KVR Audio, Inc. 2000-2024
Submit: News, Plugins, Hosts & Apps | Advertise @ KVR | Developer Account | About KVR / Contact Us | Privacy Statement