Simple DirectX development platform?

Someone must have coded a simple framework for testing DSP code under
Windows. Seems like it should be possible to simply set a buffer size,
then trigger a user-coded function to work on the buffer when it was
filled.

Does this exist?
 

Rob wrote:
> Someone must have coded a simple framework for testing DSP code under
> Windows. Seems like it should be possible to simply set a buffer size,
> then trigger a user-coded function to work on the buffer when it was
> filled.
> 
> Does this exist?

The WinAmp DSP-Plugin interface is as easy as it can get..

Regards,
   Nils

Rob wrote:
> Someone must have coded a simple framework for testing DSP code under
> Windows. Seems like it should be possible to simply set a buffer size,
> then trigger a user-coded function to work on the buffer when it was
> filled.
> 
> Does this exist?
>  
What's the significance for you of DirectX?  The standard audio plugin 
API within that is DirectSound (and DirectShow for plugins), and the 
newer ("simpler") DMO interface. Nobody generally regards those as 
"simple" however! Do you (a) know about and (b) like COM?

By far the easiest and quickest way to get real-time audio effects going 
on Windows is to use VST (Steinberg). You don't need to write a GUI as 
all hosts are required to be able to supply a default one; loads of free 
hosts are available. Initialize the effect in Resume(), and implement 
the dsp in ProcessReplacing(), add Set/GetParameter() code as you need.

(NB VST is now up to v3.0 and in a very different more COM-like form 
(not backwards-compatible) from before. You may well prefer to get hold 
of 2.4 or even 2.3, which fit my description above).

It all depends on exactly what you want to do. There are other 
solutions, such as PD (wire up elements, or write an external) and 
Csound (write an opcode, or create a User-Defined opcode or UDO), where 
you can step through the host code too if need be. Not particularly 
trivial to build those, however.

You can even do it just using Portaudio; put your dsp code in the 
callback function and run the whole thing e.g. as a combo soundfile 
player + effect. Would take more work to do an interactive one though.

Richard Dobson

On Mon, 18 Aug 2008 12:12:38 +0100, Richard Dobson
<richarddobson@blueyonder.co.uk> wrote:

>Rob wrote:
>> Someone must have coded a simple framework for testing DSP code under
>> Windows. Seems like it should be possible to simply set a buffer size,
>> then trigger a user-coded function to work on the buffer when it was
>> filled.
>> 
>> Does this exist?
>>  
>What's the significance for you of DirectX?  The standard audio plugin 
>API within that is DirectSound (and DirectShow for plugins), and the 
>newer ("simpler") DMO interface. Nobody generally regards those as 
>"simple" however! Do you (a) know about and (b) like COM?

(a) = yes. (b) = no.  No one likes COM.  <g>

I've worked with DShow via C# interface, and it's a world of
difference. I was hoping for something like that. I could probably
write it without too much trouble, but would prefer not to, given a
choice.

I'd love to figure out how to get DSP code running in C#, but of
course it wouldn't be portable.  Richard Grimes (C++/C# guru) got
impressive benchmarks with Fourier transform code in C#.

>By far the easiest and quickest way to get real-time audio effects going 
>on Windows is to use VST (Steinberg). You don't need to write a GUI as 
>all hosts are required to be able to supply a default one; loads of free 
>hosts are available. Initialize the effect in Resume(), and implement 
>the dsp in ProcessReplacing(), add Set/GetParameter() code as you need.

I've been meaning to learn about the VST interface anyway. So maybe
that's the way to go then.  I doubt the transition to .NET/C# code
would be possible, but there are other advantages.

>(NB VST is now up to v3.0 and in a very different more COM-like form 
>(not backwards-compatible) from before. You may well prefer to get hold 
>of 2.4 or even 2.3, which fit my description above).

Why would they do that in 3.0?  Sounds like a step backwards.

>It all depends on exactly what you want to do. There are other 
>solutions, such as PD (wire up elements, or write an external) and 

PD stands for...?

>Csound (write an opcode, or create a User-Defined opcode or UDO), where 
>you can step through the host code too if need be. Not particularly 
>trivial to build those, however.

Yeah, less interested in CSound.

>You can even do it just using Portaudio; put your dsp code in the 
>callback function and run the whole thing e.g. as a combo soundfile 
>player + effect. Would take more work to do an interactive one though.
>
>Richard Dobson

I'll check Portaudio as well. Thanks for the detailed reply, Richard.
Sounds like you've written VST's then?

Rob wrote:
..
> I'd love to figure out how to get DSP code running in C#, but of
> course it wouldn't be portable.  


Portability is essential for what I do (working on both Windows and OS 
X, as well as Linux occasionally). I have never looked at C#; presumably 
it at least as efficient as Java, but I would still expect code in C 
("closer to the hardware") to be faster. To say nothing here about 
hand-assembly!


..
>> (NB VST is now up to v3.0 and in a very different more COM-like form 
>> (not backwards-compatible) from before. You may well prefer to get hold 
>> of 2.4 or even 2.3, which fit my description above).
> 
> Why would they do that in 3.0?  Sounds like a step backwards.
>


You may very well ask. There was plenty of debate on the vst-dev list 
when it was launched. I think it would be fair to say opinions are 
divided. 3.0 does give a better separation between dsp thread(s) and 
editor thread(s), which matters these days when plugins may be running 
across multiple machines. It also defines side-chains properly in a way 
that previous versions did not.  I have not yet progressed beyond 2.4 
myself!


>> It all depends on exactly what you want to do. There are other 
>> solutions, such as PD (wire up elements, or write an external) and 
> 
> PD stands for...?
> 

Sorry - Pure Data - a free (GPL) alternative to MAX/MSP (graphical 
audio/MIDI programming system), developed and maintained by Miller 
Puckette plus others: http://puredata.info


..
> I'll check Portaudio as well. Thanks for the detailed reply, Richard.
> Sounds like you've written VST's then?

Yes, mostly using the phase vocoder. There are a few freebies of mine 
floating around cyberspace. Done some commercial work too, from time to 
time (i.e. stuff bundled with some app). Next upcoming challenge is 
AudioUnits and CoreAudio on the Mac, which will probably mean getting 
into Objective C. The main inhibiting factor for me (aside from being a 
dsp novice) is designing GUIs, as I am rubbish at graphic design. Slowly 
learning Photoshop at the moment.


Good luck with your projects!

Richard Dobson

Rob wrote:
> On Mon, 18 Aug 2008 12:12:38 +0100, Richard Dobson
> <richarddobson@blueyonder.co.uk> wrote:
> 
>> Rob wrote:
>>> Someone must have coded a simple framework for testing DSP code under
>>> Windows. Seems like it should be possible to simply set a buffer size,
>>> then trigger a user-coded function to work on the buffer when it was
>>> filled.
>>>
>>> Does this exist?
>>>  
>> What's the significance for you of DirectX?  The standard audio plugin 
>> API within that is DirectSound (and DirectShow for plugins), and the 
>> newer ("simpler") DMO interface. Nobody generally regards those as 
>> "simple" however! Do you (a) know about and (b) like COM?
> 
> (a) = yes. (b) = no.  No one likes COM.  <g>

That's why I recommended the winamp plugin interface.

It's all C language if you want to. All you have to do is to export 
three functins from a DLL and that's it. You can open a window to tweak 
parameters if you want to, but that's not required. The bare minimum are 
two dummy-functions and one process-function.

The workflow is nice as well if you're willing to add a post-build step.

It's my prefered platform if I tinker around with sound. You're also not 
limited to playback of media-files. If you want to you can use line-in 
as the audio-source and connect whatever signal-generator you want to 
your "work in progress"-plugin.

Nils

On Tue, 19 Aug 2008 21:26:00 +0200, Nils <n.pipenbrinck@cubic.org>
wrote:

>Rob wrote:

>> (re: Do you (a) know about and (b) like COM?)
>> 
>> (a) = yes. (b) = no.  No one likes COM.  <g>

>That's why I recommended the winamp plugin interface.
>
>It's all C language if you want to. All you have to do is to export 
>three functins from a DLL and that's it. You can open a window to tweak 
>parameters if you want to, but that's not required. The bare minimum are 
>two dummy-functions and one process-function.

That certainly sounds about as simple as it could get. I admit to
being put off by Winamp after a couple bad experiences with intrusive
installs.  Have they corrected that?  Any opinion on the best version
to use?

>The workflow is nice as well if you're willing to add a post-build step.
>
>It's my prefered platform if I tinker around with sound. You're also not 
>limited to playback of media-files. If you want to you can use line-in 
>as the audio-source and connect whatever signal-generator you want to 
>your "work in progress"-plugin.

Also good to know. I didn't realize that there was a line in.

Thanks, Nils.

On Tue, 19 Aug 2008 10:51:50 +0100, Richard Dobson
<richarddobson@blueyonder.co.uk> wrote:

>Rob wrote:
>..
>> I'd love to figure out how to get DSP code running in C#, but of
>> course it wouldn't be portable.  
>
>
>Portability is essential for what I do (working on both Windows and OS 
>X, as well as Linux occasionally). I have never looked at C#; presumably 
>it at least as efficient as Java, but I would still expect code in C 
>("closer to the hardware") to be faster. To say nothing here about 
>hand-assembly!

They say that C# can be faster than C for this reason: The "JIT"
compiler checks the type of machine that it's currently running on,
and then optimizes for the architecture of that machine.  Apparently
they've got some very clever optimizations in place, so this could be
significant.

The code gets compiled the first time it is run, so the initial run is
sort of interpreted. But then all subsequent runs are executing
tightly compiled machine code. The code can also be designated to be
'pre-compiled' so there is no impact on the initial execution. 

This is why Richard Grimes and others have reported good benchmarks
with DSP-type code.  Not sure if Java has anything like that in place.

>>> (NB VST is now up to v3.0 and in a very different more COM-like form 
>>> (not backwards-compatible) from before. You may well prefer to get hold 
>>> of 2.4 or even 2.3, which fit my description above).
>> 
>> Why would they do that in 3.0?  Sounds like a step backwards.

>You may very well ask. There was plenty of debate on the vst-dev list 
>when it was launched. I think it would be fair to say opinions are 
>divided. 3.0 does give a better separation between dsp thread(s) and 
>editor thread(s), which matters these days when plugins may be running 
>across multiple machines.

You'd think that they could have accounted for that with a separate
dev environment or something. Sounds like they are back to what COM
did in the first place, with attendant complications.


>> I'll check Portaudio as well. Thanks for the detailed reply, Richard.
>> Sounds like you've written VST's then?
>
>Yes, mostly using the phase vocoder.

Cool. Did you write a phase vocoder, or were you referring to use of
someone's existing code? 

> There are a few freebies of mine 
>floating around cyberspace. Done some commercial work too, from time to 
>time (i.e. stuff bundled with some app). Next upcoming challenge is 
>AudioUnits and CoreAudio on the Mac, which will probably mean getting 
>into Objective C. The main inhibiting factor for me (aside from being a 
>dsp novice) is designing GUIs, as I am rubbish at graphic design. Slowly 
>learning Photoshop at the moment.

Now if Adobe could write a GUI. <g>  I'm amazed at some of the quirks
that have persisted with PS.  Luckily, it is not as complex as even
rudimentary DSP coding, so you'll be fine.

Now that I'm thinking about VST code again: Do you know of any current
source code for hosting a VSTi?  I'd like to be able to generate
note-on/off events from inside one of my programs and get them played
back directly. Previous versions did generate MIDI, so the 'event'
part is not a problem.  

IOW, I'd just like to host VSTi's and send MIDI-like commands to them.

On Tue, 19 Aug 2008 14:00:04 -0800, glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

>Rob wrote:
>(snip)
>
>> They say that C# can be faster than C for this reason: The "JIT"
>> compiler checks the type of machine that it's currently running on,
>> and then optimizes for the architecture of that machine.  Apparently
>> they've got some very clever optimizations in place, so this could be
>> significant.
>
>It used to be common to compare Java to C++, but not usually C.
>
>Memory allocation and deallocation tends to be slow, and
>object-oriented programming tends to do a lot of it.
>C usually doesn't do near as much, and so likely runs
>faster for what is otherwise the same algorithm.
>
>JIT doesn't usually get around the need to do allocation
>and deallocation of objects.
>
>-- glen

Correct, but there are optimization tricks for dealing with memory in
C#. A couple of them specifically for 'pinning' allocated code blocks,
which allows local handling and prevents the memory manager from
moving them. That stuff is necessary when interfacing with legacy code
that counts on blocks remaining stationary.

Rob wrote:
(snip)

> They say that C# can be faster than C for this reason: The "JIT"
> compiler checks the type of machine that it's currently running on,
> and then optimizes for the architecture of that machine.  Apparently
> they've got some very clever optimizations in place, so this could be
> significant.

It used to be common to compare Java to C++, but not usually C.

Memory allocation and deallocation tends to be slow, and
object-oriented programming tends to do a lot of it.
C usually doesn't do near as much, and so likely runs
faster for what is otherwise the same algorithm.

JIT doesn't usually get around the need to do allocation
and deallocation of objects.

-- glen