If i understand correctly, Juce would be the solution. You say you already have the working c++ code, so you could use that and add an audioprocessor from juce to do your playback.
> Op 27 feb. 2014 om 06:36 heeft Ross Bencina <rossb-li...@audiomulch.com> het > volgende geschreven: > > Hello Mark, > >> On 27/02/2014 3:52 PM, Mark Garvin wrote: >> Most sample banks these days seem to be in NKI format (Native >> Instruments). They have the ability to map ranges of a keyboard into >> different samples so the timbres don't become munchkin-ized or >> Vader-ized. IOW, natural sound within each register. >> >> A playback engine is typically something like Native Instruments' >> Kontakt, which is 'hosted' by the main program (my composition >> software, for ex). then NI Kontakt can load up NKI files and >> deliver sound when it receives events. >> >> The whole process of linking events, etc is what usually what >> stymies programmers who are new to VST-based programming. And >> even many who are familiar. > > Yes the VST SDK is not the best documented in the world. > > >>> Personally I would avoid managed code for anything real-time (ducks). >> >> Actually, C# can be faster than pre-compiled code! > > Speed has nothing to do with real-timeness. > > Real-time is all about deterministic timing. Runtime-JIT and garbage > collection both mess with timing. It may be that CLR always JITs at load > time. That doesn't save you from GC (of course there are ways to avoid GC > stalls in C#, but if you just used a deterministic language this wouldn't be > necessary). > > >>> You're need to build a simple audio engine (consider PortAudio or the >>> ASIO SDK). And write some VSTi hosting code using the VST SDK. It's this >>> last bit that will require some work. But if you limit yourself to a >>> small number of supported plugins to begin with it should not be too >>> hard. MIDI scheduling in a VSTi is not particularly challenging -- the >>> plugins do the sub-buffer scheduling, you just need to put together a >>> frame of MIDI events for each audio frame. >> >> That's inspiring. I'm not sure that this is done in the same way as a >> regular plugin though. > > I'm not sure what you mean by "a regular plugin". > > I have a commercial VST host on the market so I do know what I'm talking > about. > > >> And I believe it's pretty difficult to host a >> VSIi in managed code. That is pretty much the crux of the problem right >> there. I've heard of a lot of people who started the project but were >> never aboe to get it off te ground. > > So you're insisting on using C# for real-time audio? As noted above I think > this is a bad idea. There is no rational reason to use C# in this situation. > > Just use unmanaged C++ for this part of your program. Things will go much > better for you. Not the least because both real-time audio APIs and the VST > SDK are unmanaged components. > > >>> If there's any kind of "synchronisation with the outside world" things >>> will get trickier, but if you can clock the MIDI time off the >>> accumulated sample position it's not hard. >> >> I could do without sync to external for now. >> >>> ... I guess the main >>> approaches would be to either (A) schedule MIDI events ahead of time >>> from your C# code and use a priority queue (Knuth Heap is easy and >>> relatively safe for real-time) in the audio thread to work out when to >>> schedule them; or (B) maintain the whole MIDI sequence in a vector and >>> just play through it from the audio thread. Then you need a mechanism to >>> update the sequence when it changes (just swap in a new one?). >> >> The internals of a VSTi host are beyond me at present. I was hoping >> for some simple thing that could be accessed by sending MIDI-like events >> to a single queue. > > I'm sure there are people who will licence you something but I don't know of > an open source solution. JUCE might have something maybe? > > Ross. > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp > links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
