Dan Nigrin

Has anyone attempted to create an MSP external using the free Dirac LE C/C++ library (formerly ClearScale) provided by Stephan Bernsee (formerlly Stephan Sprenger, of Prosoniq fame)?

http://www.bernsee.com/dspdimension.com/index.html?dirac.html

I did come across this one post on the developer list:

https://cycling74.com/forums/index.php?t=msg&goto=81391

But doesn't look like it was successful...

Has anyone attempted to create an MSP external using the free Dirac  LE C/C++ library (formerly ClearScale) provided by Stephan Bernsee (formerlly Stephan Sprenger, of Prosoniq fame)?

dirac-pitch-shifter-external

At a first glance it looks like the dirac le library is not meant for realtime processing, is it?

DIRAC is highly optimized. Its quality settings range from very fast 

to very good, with a dedicated realtime/preview mode that offers 

astonishingly good results. DIRAC STUDIO and PRO have full support 

for AltiVec optimization on the Mac and are therefore even faster 

than the LE version. Try the LE version now to sample the quality for 

It is used in many high-end software applications....

At 2:11 PM +0200 4/3/07, Mattijs Kneppers wrote:

>At a first glance it looks like the dirac le library is not meant 

>Interactive audiovisual sampling soft- and hardware

202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X / Major 

"What about realtime processing?
DIRAC is highly optimized. Its quality settings range from very fast 
to very good, with a dedicated realtime/preview mode that offers 
astonishingly good results. DIRAC STUDIO and PRO have full support 
for AltiVec optimization on the Mac and are therefore even faster 
than the LE version. Try the LE version now to sample the quality for 
yourself."

At 2:11 PM +0200 4/3/07, Mattijs Kneppers wrote:
>At a first glance it looks like the dirac le library is not meant 
>for realtime processing, is it?
>
>Mattijs
>--
>SmadSteck - http://www.smadsteck.nl
>Interactive audiovisual sampling soft- and hardware
>

-- 
Dan Nigrin
Defective Records
202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X / Major 
Malfunction
http://www.defectiverecords.com
http://www.jackosx.com

It is for realtime processing. I have successfully build an external, 

using dirac. But without using SSE or AltiVec, a single instance uses 

There is also one more problem: because of the massive use of static 

variables, the source code will only work without modification in a 

> At a first glance it looks like the dirac le library is not meant for realtime processing, is it?

> Interactive audiovisual sampling soft- and hardware

It is for realtime processing. I have successfully build an external, 
using dirac. But without using SSE or AltiVec, a single instance uses 
more than 40% on my MacBook.
There is also one more problem:  because of the massive use of static 
variables, the source code will only work without modification in a 
single instance...

Mattijs Kneppers schrieb:
> At a first glance it looks like the dirac le library is not meant for realtime processing, is it?
>
> Mattijs
> --
> SmadSteck - http://www.smadsteck.nl
> Interactive audiovisual sampling soft- and hardware
>
>


Thanks Jan - would you be willing to share the external, and perhaps 

At 2:26 PM +0200 4/3/07, Jan Thiele wrote:

>It is for realtime processing. I have successfully build an 

>external, using dirac. But without using SSE or AltiVec, a single 

>instance uses more than 40% on my MacBook.

>There is also one more problem: because of the massive use of 

>static variables, the source code will only work without 

>>At a first glance it looks like the dirac le library is not meant 

>>Interactive audiovisual sampling soft- and hardware

Thanks Jan - would you be willing to share the external, and perhaps 
the source for it?

At 2:26 PM +0200 4/3/07, Jan Thiele wrote:
>It is for realtime processing. I have successfully build an 
>external, using dirac. But without using SSE or AltiVec, a single 
>instance uses more than 40% on my MacBook.
>There is also one more problem:  because of the massive use of 
>static variables, the source code will only work without 
>modification in a single instance...
>
>Jan
>
>
>Mattijs Kneppers schrieb:
>>At a first glance it looks like the dirac le library is not meant 
>>for realtime processing, is it?
>>
>>Mattijs
>>--
>>SmadSteck - http://www.smadsteck.nl
>>Interactive audiovisual sampling soft- and hardware
>>
>>
>

-- 
Dan Nigrin
Defective Records
202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X / Major 
Malfunction
http://www.defectiverecords.com
http://www.jackosx.com


Sounds interesting. Since it is based on fft-like principles instead of granular stuff, doesn't it have an inherent latency? I could look at the code to figure that out but maybe you already know..

Quote: maxmsp@codeoperator.c wrote on Tue, 03 April 2007 14:26

----------------------------------------------------

> It is for realtime processing. I have successfully build an external, 

> using dirac. But without using SSE or AltiVec, a single instance uses 

> There is also one more problem: because of the massive use of static 

> variables, the source code will only work without modification in a 

> > At a first glance it looks like the dirac le library is not meant for realtime processing, is it?

> > Interactive audiovisual sampling soft- and hardware

Quote: maxmsp@codeoperator.c wrote on Tue, 03 April 2007 14:26
----------------------------------------------------
> It is for realtime processing. I have successfully build an external, 
> using dirac. But without using SSE or AltiVec, a single instance uses 
> more than 40% on my MacBook.
> There is also one more problem:  because of the massive use of static 
> variables, the source code will only work without modification in a 
> single instance...
>
> Jan
>
>
> Mattijs Kneppers schrieb:
> > At a first glance it looks like the dirac le library is not meant for realtime processing, is it?
> >
> > Mattijs
> > --
> > SmadSteck - http://www.smadsteck.nl
> > Interactive audiovisual sampling soft- and hardware
> >
> >
>
>
----------------------------------------------------


Is the sounding result better than gizmo~?

>> It is for realtime processing. I have successfully build an

>> external, using dirac. But without using SSE or AltiVec, a single

>> instance uses more than 40% on my MacBook.

>> There is also one more problem: because of the massive use of

>> static variables, the source code will only work without

Is the sounding result better than gizmo~?
JF.

>> It is for realtime processing. I have successfully build an
>> external, using dirac. But without using SSE or AltiVec, a single
>> instance uses more than 40% on my MacBook.
>> There is also one more problem:  because of the massive use of
>> static variables, the source code will only work without
>> modification in a single instance...
>>
>> Jan

Depending on the oversampling Factor and Frame size it sounds better than gizmo~. I'm working on a version using the DSPlib...

Yes, I have to clean up the source code a little bit, but I will post a download-link for the source code of external tomorrow. Maybe I'm able to integrate a workaround for the static problem until tomorrow.

Quote: maxmsp@codeoperator.c wrote on Wed, 04 April 2007 14:27

> Depending on the oversampling Factor and Frame size it sounds better than gizmo~. I'm working on a version using the DSPlib...

> Yes, I have to clean up the source code a little bit, but I will post a download-link for the source code of external tomorrow. Maybe I'm able to integrate a workaround for the static problem until tomorrow.

Cool. I'm really curious about the latency though. Wouldn't that depend on something like frame size / window size too?

Quote: maxmsp@codeoperator.c wrote on Wed, 04 April 2007 14:27
----------------------------------------------------
> Depending on the oversampling Factor and Frame size it sounds better than gizmo~. I'm working on a version using the DSPlib...
>
> Yes, I have to clean up the source code a little bit, but I will post a download-link for the source code of external tomorrow. Maybe I'm able to integrate a workaround for the static problem until tomorrow.
>
> Jan
>
----------------------------------------------------

Quote: maxmsp@codeoperator.c wrote on Wed, 04 April 2007 08:27

Quote: maxmsp@codeoperator.c wrote on Wed, 04 April 2007 08:27
----------------------------------------------------
> Yes, I have to clean up the source code a little bit, but I will post a download-link for the source code of external tomorrow. Maybe I'm able to integrate a workaround for the static problem until tomorrow.
>
> Jan
>
----------------------------------------------------

A second instance would push you to 80%... Sounds its not worth the 

modification. It wouldn't run on my Powerbook probably...

Jan Thiele schrieb:
> It is for realtime processing. I have successfully build an external, 
> using dirac. But without using SSE or AltiVec, a single instance uses 
> more than 40% on my MacBook.
> There is also one more problem:  because of the massive use of static 
> variables, the source code will only work without modification in a 
> single instance...

A second instance would push you to 80%... Sounds its not worth the 
modification. It wouldn't run on my Powerbook probably...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


As yesterday promised the link for my dirac implementation. It is not perfect, I only spend an hour to test the code for implementation in COModPack...

http://www.codeoperator.com/downloads/dirac.zip

The zip file includes a UB module of dirac and the Xcode project with the source code.

the link:
http://www.codeoperator.com/downloads/dirac.zip

I tried your external. Everything works fine. The sound when pitch shifting doesn't sound correct to me though. I made a recording:

http://avdl1064.oli.tudelft.nl/dirac-recording.aif

I've had some email contact about this with Stephan M.Bernsee and he says he'd be happy to help anyone who wants to give this a go.

Quote: maxmsp@codeoperator.c wrote on Thu, 05 April 2007 07:59

> As yesterday promised the link for my dirac implementation. It is not perfect, I only spend an hour to test the code for implementation in COModPack...

> The zip file includes a UB module of dirac and the Xcode project with the source code.

Quote: maxmsp@codeoperator.c wrote on Thu, 05 April 2007 07:59
----------------------------------------------------
> As yesterday promised the link for my dirac implementation. It is not perfect, I only spend an hour to test the code for implementation in COModPack...
>
> the link:
> http://www.codeoperator.com/downloads/dirac.zip
>
> The zip file includes a UB module of dirac and the Xcode project with the source code.
>
> Jan
----------------------------------------------------


What fftFrameSize and Oversampling rate did you use? I only tested dirac~ with a short voice recording and it sounded good at an oversampling rate of 16 or 32. But as I said, I only tested it for a very short time. I was only curious if I could make an external of the smbPitchShift code. An implementation using SSE or AltiVec is what I'm working on -> with low priority... due to other things I have on my desk :-(

You should not forget, that this is a simple implementation of DIRAC compared to what you can hear in Prosoniq's TimeFactory...

You will get better results with DIRAC Pro or Studio.

What fftFrameSize and Oversampling rate did you use? I only tested dirac~ with a short voice recording and it sounded good at an oversampling rate of 16 or 32. But as I said, I only tested it for a very short time. I was only curious if I could make an external of the smbPitchShift code. An implementation using SSE or AltiVec is what I'm working on -> with low priority... due to other things I have on my desk :-( 

You should not forget, that this is a simple implementation of DIRAC compared to what you can hear in Prosoniq's TimeFactory...
You will get better results with DIRAC Pro or Studio.

I used the arguments that were in your help file: 4096 8

I don't think it's only the quality of the algorithm. The results sound clickery, like something is wrong in the processing loop.

I used the arguments that were in your help file: 4096 8 

> As yesterday promised the link for my dirac implementation.

> The zip file includes a UB module of dirac and the Xcode project 

I already worked on this code. This is smbPitchShift.cpp, not Dirac.

smbPitchShift.cpp is a good code for learning how to write a decent pitch-shifter, but needing a lot of improvements, vectorization, etc.

When done, it can work fine, in real-time when playing an instrument with no audible latency, with a CPU load at around 20% on the current Mac, and sounds good.

Quote: maxmsp@codeoperator.c wrote on Thu, 05 April 2007 07:59
----------------------------------------------------
> As yesterday promised the link for my dirac implementation.
> http://www.codeoperator.com/downloads/dirac.zip
> The zip file includes a UB module of dirac and the Xcode project 
> with the source code.
----------------------------------------------------

I already worked on this code. This is smbPitchShift.cpp, not Dirac.
smbPitchShift.cpp is a good code for learning how to write a decent pitch-shifter, but needing a lot of improvements, vectorization, etc.
When done, it can work fine, in real-time when playing an instrument with no audible latency, with a CPU load at around 20% on the current Mac, and sounds good.

Quote: Mattijs wrote on Thu, 05 April 2007 11:35

> I used the arguments that were in your help file: 4096 8 

> I don't think it's only the quality of the algorithm.

> The results sound clickery, like something is wrong in the

Go to the DSP Status and increase I/O and Signal Vector Size, both.

Try from maximum values, then decrease...

And in the patcher, play with a float instead of an integer number box.

Quote: Mattijs wrote on Thu, 05 April 2007 11:35
----------------------------------------------------
> I used the arguments that were in your help file: 4096 8 
> I don't think it's only the quality of the algorithm.
> The results sound clickery, like something is wrong in the
> processing loop.
----------------------------------------------------

Go to the DSP Status and increase I/O and Signal Vector Size, both.
Try from maximum values, then decrease...
And in the patcher, play with a float instead of an integer number box.

Thanks Jan for the code! I got it working fairly well, especially when I lowered the frame size quite a bit (down to 128), and oversampling at 32. Of course, even on a MacPro Quad 3 GHz, it consumed about 50% CPU though...

I must admit though, not nearly as good as I was hoping for. I guess Pro/Studio is required...

Thanks Jan for the code!  I got it working fairly well, especially when I lowered the frame size quite a bit (down to 128), and oversampling at 32.  Of course, even on a MacPro Quad 3 GHz, it consumed about 50% CPU though...

I must admit though, not nearly as good as I was hoping for.  I guess Pro/Studio is required...

I directed Stephen Bernsee himself to this thread, and he pointed out to me that the code Jan used (smbPitchShift.cpp) has nothing to do with DIRAC - here's what he said:

"from the thread in the forum I gather that he's not actually using DIRAC but rather the free SMBPitchShift() source code that is available as part of the "Pitch Shifting Using the Fourier Transform" article.

SMBPitchShift() has nothing to do with DIRAC, it's more related to a phase vocoder than to the kind of processing that DIRAC uses and it is nowhere near as good as DIRAC."

So perhaps that's why the results were not as exciting as I had hoped for originally... Jan, have you looked at the actual DIRAC code? Maybe it wouldn't be hard to port what you have done already to use it instead?

----------
"from the thread in the forum I gather that he's not actually using DIRAC but rather the free SMBPitchShift() source code that is available as part of the "Pitch Shifting Using the Fourier Transform" article.

SMBPitchShift() has nothing to do with DIRAC, it's more related to a phase vocoder than to the kind of processing that DIRAC uses and it is nowhere near as good as DIRAC."
----------

So perhaps that's why the results were not as exciting as I had hoped for originally...  Jan, have you looked at the actual DIRAC code?  Maybe it wouldn't be hard to port what you have done already to use it instead?

Quote: Dan Nigrin wrote on Mon, 09 April 2007 20:11

> Jan, have you looked at the actual DIRAC code?

> Maybe it wouldn't be hard to port what you have done

The purpose of "Dirac LE" (free) is to demonstrate the sonic quality of Dirac.

LE, Studio and Pro come as a set of compiled libraries to include in a project, like "libDiracLE.a". No source code provided, just some examples.

Quote: Dan Nigrin wrote on Mon, 09 April 2007 20:11
----------------------------------------------------
> Jan, have you looked at the actual DIRAC code?
> Maybe it wouldn't be hard to port what you have done
> already to use it instead?
----------------------------------------------------

Dirac is something really different.
The purpose of "Dirac LE" (free) is to demonstrate the sonic quality of Dirac.
LE, Studio and Pro come as a set of compiled libraries to include in a project, like "libDiracLE.a". No source code provided, just some examples.

> So perhaps that's why the results were not as exciting as I had hoped for originally...

I don't know abot the performance of DIRAC, but I too made a pitch 

shifter external based on smbPitchShift.cpp a few years ago. In order to 

make it useable on a Mac I had to write an Altivec version of it to get 

CPU usage down. But it was still at around 25% in a 733MHz G4.

Dan Nigrin wrote:
> So perhaps that's why the results were not as exciting as I had hoped for originally...  

I don't know abot the performance of DIRAC, but I too made a pitch 
shifter external based on smbPitchShift.cpp a few years ago. In order to 
make it useable on a Mac I had to write an Altivec version of it to get 
CPU usage down. But it was still at around 25% in a 733MHz G4.

> I don't know about the performance of DIRAC, but I too made a pitch 

> shifter external based on smbPitchShift.cpp a few years ago. In 

> order to make it useable on a Mac I had to write an Altivec version 

> of it to get CPU usage down. But it was still at around 25% in a 

As you know, I gave up with it for MaxMSP because I needed to use the 

Accelerate framework to vectorize the all code for "i386 ppc".

I'm still using this vectorized smbPitchShift.cpp for real-time 

processing with a very low (inaudible) latency when playing an 

Up to 6 voices of polyphony per instance for pitch-shifting on per 

note basis, I get an average CPU load at 22% on tested machines.

About DIRAC, do you know a software that uses this code? I'd like to 

Olaf Matthes wrote:
> I don't know about the performance of DIRAC, but I too made a pitch  
> shifter external based on smbPitchShift.cpp a few years ago. In  
> order to make it useable on a Mac I had to write an Altivec version  
> of it to get CPU usage down. But it was still at around 25% in a  
> 733MHz G4.

As you know, I gave up with it for MaxMSP because I needed to use the  
Accelerate framework to vectorize the all code for "i386 ppc".
I'm still using this vectorized smbPitchShift.cpp for real-time  
processing with a very low (inaudible) latency when playing an  
instrument or when singing.
Up to 6 voices of polyphony per instance for pitch-shifting on per  
note basis, I get an average CPU load at 22% on tested machines.

About DIRAC, do you know a software that uses this code? I'd like to  
hear.

>The purpose of "Dirac LE" (free) is to demonstrate the sonic quality of Dirac.

>LE, Studio and Pro come as a set of compiled libraries to include in 

>a project, like "libDiracLE.a". No source code provided, just some 

As I've not ever written my own external - can one link to compiled 

libraries when building a Max/MSP external? In other words, is it 

*possible* to build one using the DIRAC LE libraries?

>Dirac is something really different.
>The purpose of "Dirac LE" (free) is to demonstrate the sonic quality of Dirac.
>LE, Studio and Pro come as a set of compiled libraries to include in 
>a project, like "libDiracLE.a". No source code provided, just some 
>examples.

As I've not ever written my own external - can one link to compiled 
libraries when building a Max/MSP external?  In other words, is it 
*possible* to build one using the DIRAC LE libraries?

Thanks,
Dan
-- 
Dan Nigrin
Defective Records
202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X / Major 
Malfunction
http://www.defectiverecords.com
http://www.jackosx.com


>About DIRAC, do you know a software that uses this code? I'd like to hear.

Steinberg's Wavelab 6 is one I believe...

Dan
-- 
Dan Nigrin
Defective Records
202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X / Major 
Malfunction
http://www.defectiverecords.com
http://www.jackosx.com


http://www.dspdimension.com/index.html?news.html

And also Autodesk - see http://www.dspdimension.com/index.html?news.html

>> The purpose of "Dirac LE" (free) is to demonstrate the sonic 

>> LE, Studio and Pro come as a set of compiled libraries to include 

>> in a project, like "libDiracLE.a". No source code provided, just 

> As I've not ever written my own external - can one link to compiled 

> libraries when building a Max/MSP external? In other words, is it 

> *possible* to build one using the DIRAC LE libraries?

Normally yes, by including "libDiracLE.a" in your project.

I don't see anything in the provided example ("DiracTestLE") that 

(About WaveLab, nothing to see, nothing to hear...)

I wrote:
>> The purpose of "Dirac LE" (free) is to demonstrate the sonic  
>> quality of Dirac.
>> LE, Studio and Pro come as a set of compiled libraries to include  
>> in a project, like "libDiracLE.a". No source code provided, just  
>> some examples.

Dan Nigrin:
> As I've not ever written my own external - can one link to compiled  
> libraries when building a Max/MSP external?  In other words, is it  
> *possible* to build one using the DIRAC LE libraries?

Normally yes, by including "libDiracLE.a" in your project.
I don't see anything in the provided example ("DiracTestLE") that  
could fail. But I never tried.

About the vectorized optimization of "smbPitchShift.cpp" (a shared project), here some audio tests played in true real-time with no post-processing at all, no audio hardware other than the built-in audio of a Mac in which a guitar is directly plugged, at 48 kHz - 24 bit, mono input, stereo output.

What you'll hear is what has been played. No less, no more.

The next Real-Time generation? I think so.

The first played scales are diatonic, the following are more and more chromatic and the latest use microtuning scales.

Finally, the last example is played through a simple pentatonic scale but with up to 6 voices of polyphony.

No contest about musical styles. That's only to illustrate what it's possible to do nowadays with a code based on discrete transform like FFT, iFFT and STFT. No pitch formant correction applied.

I'd be very glad to get your questions or comments. They could help me a lot to improve the software.

And if some of you like those examples, drop me a line about my 'musical side' ;-)

Under "Real-time pitch-shifting your audio input" at:

About the vectorized optimization of "smbPitchShift.cpp" (a shared project), here some audio tests played in true real-time with no post-processing at all, no audio hardware other than the built-in audio of a Mac in which a guitar is directly plugged, at 48 kHz - 24 bit, mono input, stereo output.
Host software: AU Lab 1.0.3

What you'll hear is what has been played. No less, no more.
The next Real-Time generation? I think so.

The first played scales are diatonic, the following are more and more chromatic and the latest use microtuning scales.
Finally, the last example is played through a simple pentatonic scale but with up to 6 voices of polyphony.

I'd be very glad to get your questions or comments. They could help me a lot to improve the software.
And if some of you like those examples, drop me a line about my 'musical side' ;-)

thank you for your interest in Dirac. Dan Nigrin pointed me to this forum and I understand that there is an interest in a Dirac external for Max/MSP. While I'm not sure if it makes sense for us to purchase the full $500 Max/MSP package to develop a free Dirac LE external for it (for several reasons) I would be happy to help anybody who would like to do it.

A few things regarding the questions that have been brought up here: the code that you are using right now is the smbPitchShift code from my "Pitch Shifting Using the Fourier Transform" article. This code has nothing to do with Dirac, and is in fact of inferior quality. It is intended as a tutorial to get people started in the right direction (I was told it has been useful to develop the polyphonic time stretching used in the latest Melodyne), but without refinement it has more of an experimental quality to it and isn't really something to be used in a high quality application.

Dirac can be a bit complicated if you want to use it in a realtime context, since it relies on a callback method to deliver input data (time stretching requires different rates for input and output). This can be tricky if you want to use it realtime because you might need a rather large buffer size to keep some of the input data available. And although Dirac can be used as a realtime time stretching, its primary emphasis is on quality, not speed.

Regarding products that use Dirac, there are several. If you're into video editing you might know the software made by the Austrian company Stumpfl or by the Canada based company Autodesk/Discreet. Also, the upcoming Prosoniq TimeFactory 2 for Mac uses it (

Please let me know if you have further questions, I'd be happy to answer them either by PM or in this forum.

Regarding products that use Dirac, there are several. If you're into video editing you might know the software made by the Austrian company Stumpfl or by the Canada based company Autodesk/Discreet. Also, the upcoming Prosoniq TimeFactory 2 for Mac uses it (http://www.prosoniq.com) as well as Steinberg's Wavelab (http://www.steinberg.de/134_1.html), amongst others.

I recently downloaded a copy of the dirac source code and tried to compile it using visual studio on a pc. It came up with this as an error message:

error C2668: 'log' : ambiguous call overloaded function

I'm guessing that the fftFrameSize may not have been set??

Before I put my head into it, I thought I would ask the experts.

error C2668: 'log' : ambiguous call overloaded function
File smbPitchshift.cpp, Line 410 

I'm guessing that the fftFrameSize may not have been set??
Before I put my head into it, I thought I would ask the experts.

Again (I just mentioned this in the message that you were replying to): this is NOT the Dirac source code, it has nothing to do with it. It is code for an article that I wrote back in the 90s which deals with pitch shifting using the Fourier transform.

As for your question: Since there is no line 410 in the original smbPitchShift.cpp you would have to tell us what is going on in your source code before anybody could comment on it.

Dirac pitch shifter external?