An open standard for assembling DAWs could be useful.
A DAW can be considered as the interaction of components such as:
- Mixer
- X plugin format handler
- Y plugin format handler
- Z plugin format handler
- ...
- Clip layout panel (song timeline)
- Wave editor
- Midi clip editor
and so on.
The open standard would specify the conditions to be met so that your wonderful component could be integrated in whatever barebone DAW.
In other words, a DAW could be (even dynamically) constructed starting from a barebone DAW by loading your favorite components. Components could be either self made or from third parties.
DAW construction kit
-
- KVRist
- Topic Starter
- 288 posts since 18 Mar, 2012
What do you, daw users, think about DAW construction kits ?
viewtopic.php?f=33&t=564851&p=8103262#p8103262
viewtopic.php?f=33&t=564851&p=8103262#p8103262
-
- addled muppet weed
- 105855 posts since 26 Jan, 2003 from through the looking glass
-
- addled muppet weed
- 105855 posts since 26 Jan, 2003 from through the looking glass
-
- KVRist
- Topic Starter
- 288 posts since 18 Mar, 2012
To develop a DAW you need a compiler, first. Then if you don't want to start from scratch, you could use some third party components. In this way (hopefully) you could get started in a few months, rather than some year.
What's belt? A new programming language for a new OS called Bum Crack?
-
- Banned
- 11467 posts since 4 Jan, 2017 from Warsaw, Poland
On paper it sounds interesting, but in practice the HOW certain feature is implemented and HOW it works with everything else decides about DAWs' appeal. It would be really difficult to build an environment covering e.g. different "flavours" of sequencers, mixers, device chains, etc. And if there would only be one of each, then what's the point? I don't have to build a DAW that has e.g. musical notation and video track removed - I don't mind they're there in S1 or Cubase, I just never use them.bitwise wrote: ↑Thu May 06, 2021 11:30 am What do you, daw users, think about DAW construction kits ?
viewtopic.php?f=33&t=564851&p=8103262#p8103262
-
- KVRist
- Topic Starter
- 288 posts since 18 Mar, 2012
antic604 wrote: ↑Thu May 06, 2021 11:57 amOn paper it sounds interesting, but in practice the HOW certain feature is implemented and HOW it works with everything else decides about DAWs' appeal. It would be really difficult to build an environment covering e.g. different "flavours" of sequencers, mixers, device chains, etc. And if there would only be one of each, then what's the point? I don't have to build a DAW that has e.g. musical notation and video track removed - I don't mind they're there in S1 or Cubase, I just never use them.bitwise wrote: ↑Thu May 06, 2021 11:30 am What do you, daw users, think about DAW construction kits ?
viewtopic.php?f=33&t=564851&p=8103262#p8103262
The main purpose of a daw construction kit is not the customization of the daw. The need of the kit is to allow the creation of a daw by developers shortening the development times. That's why i put the description in the development forum. Yet, users' opinions are welcome.
-
- Banned
- 11467 posts since 4 Jan, 2017 from Warsaw, Poland
Yes, but that's my point - without ability to heavily customise the components (e.g. compare Reason's rack, to Bitwig's device chain to Cubase's inserts list) you'd quickly end up with n DAWs all working & looking the same. Like for example you could immediately tell a game was made in Unity in their early years.bitwise wrote: ↑Thu May 06, 2021 12:17 pmThe main purpose of a daw construction kit is not the customization of the daw. The need of the kit is to allow the creation of a daw by developers shortening the development times. That's why i put the description in the development forum. Yet, users' opinions are welcome.
BTW, is this just a thought experiment, or do you actually have knowledge & skills to pull this off?
-
- Banned
- 334 posts since 11 Jan, 2015
don't get me wrong, but why would we need more daws if they're then doing all the same and why would one have the idea to just create a daw at all? especially since we can customize the current daws already more and more.
-
- KVRist
- Topic Starter
- 288 posts since 18 Mar, 2012
You don't have to agree. Some year ago someone asked for something similar and i remember it didn't gather a lot of interest. So i don't expect a lot of interest now. Developing a daw takes time and money and if you invest money for that, it must bring you more money back. You can't fail so, to avoid any risk, you do it like all the successful ones. But if developing a daw was cheaper you would have a chance to do it differently in a way that "hopefully" suits your needs and if it doesn't you can start experimenting again without rebuilding everything from scratch.
-
- KVRian
- 1111 posts since 3 May, 2005 from Victoria, BC
There is Tracktion Engine: https://github.com/tracktion/tracktion_engine
You can get a DAW like application going with not much code.
You can get a DAW like application going with not much code.
-
- KVRist
- Topic Starter
- 288 posts since 18 Mar, 2012
I'm talking about main building blocks which have a defined interface with the outside world. For example, you could create a Mixer Track Component which, internally may behave as you want, as long as you can plug it inside the Mixer Component flawlessy.antic604 wrote: ↑Thu May 06, 2021 12:38 pm Yes, but that's my point - without ability to heavily customise the components (e.g. compare Reason's rack, to Bitwig's device chain to Cubase's inserts list) you'd quickly end up with n DAWs all working & looking the same. Like for example you could immediately tell a game was made in Unity in their early years.
I developed a DAW and, as i saw the time passing by, i realized that i hadn't event started to implement the feature for which i decided to start the project. So i spent a lot of time reinventing the wheel. And a new born project surely has lots more bugs than a tested one. If you could replace a single component in a well tested project, it would save you a lot of time and efforts.
-
- KVRAF
- 7748 posts since 13 Jan, 2003 from Darkest Kent, UK
You'd be adding levels of abstraction which I don't think would be very useful. Take the plugin handler for instance; you'd be hosting a plugin and talking to it through the VST (say) protocol, have you read the VST specs? Lots of parameters and event controls to deal with. So you get audio data(?) from the plug, then what? Pass it through another set of protocols (your new ones) to get it to where ever you want it to go?
To me, it sounds like you want a fully modular host that you can add elements too. Bit like EnergyXT, have loads of sequencers playing at different tempos, pattern lengths etc feeding midi and audio to VSTs and inbuilt effects. If you wanted to add a custom processor just use the VST protocol. Add a VST mixer and route what you want to it.
To me, it sounds like you want a fully modular host that you can add elements too. Bit like EnergyXT, have loads of sequencers playing at different tempos, pattern lengths etc feeding midi and audio to VSTs and inbuilt effects. If you wanted to add a custom processor just use the VST protocol. Add a VST mixer and route what you want to it.
