I think a one-shot (if that's what you're suggesting) clone is somewhat unrealistic. I agree with you.

On the other hand, refining/tweaking over time may get you closer. I'm quite far down this road, having created a DAW of my own flavor.

It's absolutely not perfect, nor is it a production-level app or even clone, but I trust it for electronic music production because it, like many other programs, does the basics well.

That's another point worth making about the assets. They're a barrier as someone builds them over time. You might have 2000 (example) custom presets and audio file alterations in Ableton and use them as your "sound" as a producer.

Thinking names like Kaskade, Deadmau5, etc. Plenty of others.

Going back to the code, reverb is the example that illuminates the difficulty of cloning in my day-to-day. Sometimes quite explicit in songs, and sometimes hiding just enough in the background. But IMO - stands out immediately when it sounds "off" as I lack a better description.

Anyhow, here's my song from my DAW in case you're curious! Note that it's not mastered so you'll need to crank your volume somewhat.

https://on.soundcloud.com/grJ3e8EAzMc87pFzLX

▲

nonethewiser 10 minutes ago | parent | next [-]

And in your experience, what is harder? Sound design or coding the app?

I mean there are some sounds in the public domain or things that you can synthesize yourself. But I'm talking about the basic sounds that people ahve come to expect from DAWs, like TR808 or 909. You probably don't have those, have your own versions which don't sound quite right, or versions you cannot redistribute in a DAW. If you have solid versions please tell me, because I would like to learn.

BTW I'm not saying YOUR app needs those for YOUR purposes but I'm asking to help clarify my original claim that the sound design will be the bigger bottleneck.

▲

diskzero 2 hours ago | parent | prev [-]

The main argument to me in creating your own DAW is that you have some workflow that simply can't be done with the other tools. Otherwise, you are going to spend massive amounts of time just to replicate Ableton 1.0, let alone Live 13.

Thanks for sharing the song. This is material proof that your program can generate a composition. Did you come up with some new ideas about how to create and produce?

▲

grvdrm an hour ago | parent [-]

I don't think I have anything groundbreaking yet.

Blending lots of ideas from other places (unsurprising I'm sure). I first used FL Studio, and am more recently an owner of Ableton. Some things I like and dislike about both, so what I tried to do with my app is blend what I like.

E.g. FL Studio = step sequencer. Ableton = more intuitive (I think) for whole song composition. Of course, now Live 13 has a Step Sequencer...

The other areas I'm exploring is sound design. One goal in this effort is to remove dependencies on other tools as much as possible. So every sound you heard in my song is from the app alone - not some external sample or other synth/VST tool.

So, then suppose you sit down with a blank slate and draw a wave. Preview it. Now add bits and pieces on top. But more of a visual design canvas rather than the Reason-style rack wiring.

PS: Thank you for checking out the song!

▲

diskzero an hour ago | parent [-]

How did you implement the side-chain compression? (I think I am hearing that.) We can also move offline of HN if you would rather discuss there. gene at semitone dot audio.

	▲	grvdrm 26 minutes ago \| parent [-]
		Happy to do both! But answering here if I understand correctly: I use (at the moment) a mostly serial chain architecture. I think what you're asking is whether I'm using signals from one instrument (or other component) to drive another. Not as much as a first class feature similar to what you'd find in Ableton. So, for example, I don't have today something that will drive low-pass cutoff frequency on a synth based on the kick drum sine wave decay. Same idea you're mentioning? On my list to get to but not there yet! I tend to add things as they come up in the process of making music, rather than approach this as a software-first-music-second project.