I'm curious how you're thinking of solving latency & disconnection issues between participants. It looks like you're representing things as a sequential list of transactions, and immutable transactions are definitely the starting point for everything I've considered! The question is: what happens if multiple people send each other conflicting transactions at the same time? Google Wave solved this by enforcing a single server-side ordering of all events, and making sure that all transactions would be accepted using Operational Transformation even if they occurred out of order. Without OT, you may have cases where Alice makes a change, only to have it invalidated and essentially erased by Bob's change that may have "won" on the server side. And while OT may be largely "solved" for text content, it doesn't seem well-studied for music or other timeline-based content.
As an alternative, source control manages to get along fine without automated conflict resolution/OT, since we're willing to dive into merge conflicts and resolve things ourselves. So theoretically, you could create "Git for Music" and drive that from your app. But what's the UI equivalent of version control in a DAW? What, exactly, does a "diff" look like in musical notation? And how do you make it unobtrusive to non-coder musicians?
All very interesting problems, and it's always great to have multiple innovators in this space! Would be happy to connect offline if you'd like.
I've planned this out on paper. It's going to be solved in a peer to peer manner, no central server. It will work the same way that git rebasing works. When conflicting transactions occur simultaneously, there is a deterministic way to determine the order, then each peer rebases the transaction and resolves conflicts automatically in a deterministic way.
Undo/redo is really complicated, but I believe I have a pragmatic approach that will work. I don't expect users to resolve conflicts; instead I will make the effort of editing small and leave it to users to manually correct automatic conflict resolution if there is a problem. No "diff"s, no coding knowledge necessary.
Do feel free to email me if you want to chat about this problem :)
2) any plans on support OSS for things like *BSD/Solaris ?
3) plans to support writing out to disk with even a single format, like .au, or .wav ?
I'm looking forward to playing with this !
BSD/Solaris support is within scope, however I am now going to focus my development efforts on Genesis DAW . So the way that these other backends can get support is:
* someone contributes code
* enough is contributed financially to support me working on more backends.
> plans to support writing out to disk with even a single format, like .au, or .wav ?
Would you like to file an issue and explain the use case? Let's talk it over.
I'm trying to go for the very opposite of "walled garden" so I'm really interested to hear your concerns about that and how I could make it better.
For me UI is more important than feature-set; the interface that doesn't get in my way increases my creativity. Especially if I'm recording and I have to switch between playing instruments and operating complicated software. The only DAW that I think gets it right is MultitrackStudio, with perfect combination of features and effortless interface.
Latency - It isn't bad for vocals or if you are playing a single audio source, but if you have multiple of sound sources and ALSA and JACK devices playing how are you going to handle latency?
And as a side note, that is definitely the way to go. WASAPI is a massive improvement over previous windows audio APIs, especially for low latency / pro audio. I'm flabbergasted that some DAWs still don't support it.
Also, templates don't always work equally well across compilers. You'd really be better off with pure C.
This looks like an excellent library, so please don't take that as criticism, just an observation.
The only time they are not is if you explicitly use options that prevent them from doing so; in the case of gcc, that's the -nostdlib or -nodefaultlibs as appropriate to your scenario.
I do appreciate that you actually checked the output of ldd.
Regardless, again, only as an observation, you'd still be better off with pure C. Even if you don't use standard C++ libraries, and have eliminated the need for any special runtimes, the rules of C and C++ are not the same, even as of C11/C++11. So there may be subtle interoperability concerns.
Again, this is all merely observation; I haven't yet used your library, only airing potential technical concerns you may wish to research.
Regardless, thanks again for your excellent contribution to the community!
It is something I am looking already some time for a multiplatform way to get the main mix stream.
int default_out_device_index = soundio_default_output_device_index(soundio);
I guess it would be a pretty unique addition to have a method to grab the main mix on Windows, Linux, and OS X in a common way!