Ok, finally have some time. First of all, thanks for all the nice welcome-backs and such, it's appreciated
Some documentation would help though.
Yes, I should get to that ASAP.
* Realtime control over parameters of the sound, like. (ChangeParameter(instrument,...) or something similar.)
Yes, I've definitely thought about something like this, and it shouldn't be hard to implement. I guess I'll do this soon.
* More than 2 oscillators per instrument?
Would certainly be attractive. So far, I stuck to only 2 for several reasons. First of all, the plan was to keep synthesis cheap enough to run in the background of a game which does a fair amount of processing itself. Besides, the 2 oscillators plus filter layout is sort of a classic design of (soft)synths, so it's immediately familiar to anyone who has done some synth programming. (In fact, if you know the synth1 VST, I've copied a lot of its layout.) Finally, having a variable number of oscillators would probably necessitate a more modular design which could complicate things, both internally and for the user. On the other hand, just adding an optional third oscillator which gets mixed in with the others would be more or less a triviality to add, so that's definitely an option if people want it.
* Polyphonic instruments? (PlayChord(...) or something similar... Multiple PlayNote()s with the same start time? Didn't try that yet...)
Yep, multiple PlayNote()s do work. Just watch the volume so that you don't get clipping. I'm not sure yet how to deal with this whole volume business properly. Anyway, you can try it in the CosPlay sample application, just hit several keys at once.
And to get the library working in C++, I had to change those macros in the cosyne.h file like this:
Ah, thanks for this, forgot to try it in C++. Will update the header file accordingly.
Still I'm not so sure if I used the right method to play notes interactively, after pressing a button. I tried it like this:
Cosyne_PlayNote( c, Cosyne_GetCurrentTime( c ), 20000, INSTR_XYZ, 40, 0x40 );
That worked for me, although the timing is a bit off that way, because OpenAL (and other Audio APIs too) only asks for buffer updates in certain intervals, so that PlayNote() events are only as accurate as the buffer size allows... But it doesn't sound so bad, and adds some "analog qualities" to it
.
(Probably there's a way around this though, by adding an offset manually, but I didn't try that yet... Instead of a buffer based render function, a sample based render function could also help with this maybe, although that would make the performance go down...)
The way you tried was fine. (As a shorthand, you can use -1 instead of GetCurrentTime(), or maybe 0xFFFFFFFF if the compiler complains about signed-unsigned mismatch.)
Cosyne internally works with chunks of 64 samples instead of processing each sample individually to keep the CPU load manageable. If each chunk could be output immediately without delay, at a sample rate of 44.1kHz, this would correspond to a latency of 64/44100 = 1.45ms, which is basically realtime as far as humans are concerned. So this design shouldn't be a problem.
The problem is how to get the data to your soundcard as quickly as possible. As you mentioned, all audio APIs have some kind of cyclic buffer for audio data. The key point is the size of this buffer, which the API should let you choose upon initialization. If it's too large, you will get bad latency, if it's too small, audio will crackle and skip. This is to some degree hardware dependent, so I guess you should offer it as an option to your user, but in general I've found that 512 samples is an acceptable compromise.
Keep in mind that a game running at 60fps corresponds to having 735 samples per frame (at 44.1khz), so a 512 samples buffer should be just fine to keep perfect sync with the video.
By the way, I had an idea about MML (
http://en.wikipedia.org/wiki/Music_Macro_Language), which found out about
there a while ago... That's some crazy stuff for sure, and maybe the way it handles sequencing could be useful here too. I don't really understand how all this MML stuff works though, but it seems to be very powerful.. Maybe a separate library for sequencing only could be an other "module" of this toolkit, just an idea I had... Something like macros (for example for defining things like an arpeggiator, scales and rhythms), could be defined in seperate small scripts, which are generating note/parameter events, passing over to cosyne. Some parameters could be controlled interactively... It's a quite cloudy idea though... Don't now how it could be implemented myself
Yes, that's very interesting stuff. I also did some stuff with procedural composition in Python a while back which I could now hook up to Cosyne (maybe you can still find the thread here). In general, I think these sorts of things should be implemented on top of Cosyne, not within it: I've decided to keep the engine closely focused on efficient generation of audio data. This is why the score functionality is so rudimentary and doesn't even offer something like a beats per minute setting, just raw sample counts. (Though maybe seconds would be nicer.)
I'd just love to edit instruments and possibly even "interactive sequences", while the final program keeps running... However, that's probably quite difficult with text based code files.
A very nice thought, and I think not even that hard to implement. Just check if the file has been modified (usually the OS will give you some kind of hook to listen for this, Windows does at least), and if so, reload it.
I also tried my hands on making a audio synth library (called 'executable sound'), you might remember it... It's still not fully finished though, but I'm working on it again soon. Mine isn't so "score" oriented, and it's harder to play notes and to define separate instruments the easily... And it can't be used in pure code/text, which makes things more difficult in practice.
Yes, I remember it, it was included with that 3D flying game of yours, right? (Occuplector or something like that, IIRC.) It was very cool, though it took a long while to render. Would definitely love to see any progress on that.
- This is one point that is really cool about your library. It's easy to make the most obvious thing: Play a note with an instrument! That's really useful.
Yes, ease of use (and binding to other languages) was a goal with this.
Community
