Dirac pitch shifter external?
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)?
I did come across this one post on the developer list:
But doesn't look like it was successful...
Thanks,
Dan
At a first glance it looks like the dirac le library is not meant for realtime processing, is it?
Mattijs
Yes, it is:
"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."
It is used in many high-end software applications....
Dan
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
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
>
>
Thanks Jan - would you be willing to share the external, and perhaps
the source for it?
Dan
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..
Mattijs
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~?
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.
Jan
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
>
----------------------------------------------------
Cool. I'm really curious about the latency though. Wouldn't that depend on something like frame size / window size too?
Mattijs
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
>
----------------------------------------------------
Excellent news Jan, thanks in advance!
Dan
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
--
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...
The zip file includes a UB module of dirac and the Xcode project with the source code.
Jan
Hi Jan,
I tried your external. Everything works fine. The sound when pitch shifting doesn't sound correct to me though. I made a recording:
CPU usage is 15% on a Mac Pro 2,66 GHz.
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.
Cheers,
Mattijs
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.
Jan
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.
Priorities.. I know all about it :p
Mattijs
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.
Good luck!
Philippe
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.
Cheers ;-)
PG
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...
Best,
Dan
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?
Thanks,
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?
----------------------------------------------------
Hi Dan,
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.
Best,
Philippe
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.
Olaf
Hi Olaf !
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.
Best,
Philippe
>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.
Thanks Philippe, I understand.
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
>About DIRAC, do you know a software that uses this code? I'd like to hear.
And also Autodesk - see http://www.dspdimension.com/index.html?news.html
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
Hi Dan,
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 WaveLab, nothing to see, nothing to hear...)
Bye,
PG
Hi Max fans!
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.
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:
Cheerio,
Philippe
Hi all,
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 (http://www.prosoniq.com) as well as Steinberg's Wavelab (http://www.steinberg.de/134_1.html), amongst others.
Please let me know if you have further questions, I'd be happy to answer them either by PM or in this forum.
Best wishes,
--smb
Howdy,
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
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.
Many thanks,
jJ
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.
Btw. I recommend you post questions such as these to the DSPdimension forum at http://www.surroundsfx.com/forum as I am not sure whether or not the moderators here would consider them to be OT.
Best wishes
--smb
Thanks Stephan for your great support!
Here a screenshot as preview for the oncoming v2.0 of "Diatonic Shifter" (written by Frank Schoep and I) also based on "smbPitchShift.cpp" code, fully vectorized, and embedding a real-time pitch-tracker.
Best,
Philippe
[img]index.php?t=getfile&id=586&private=0[/img]
Stephan Bernsee schrieb:
> Btw. I recommend you post questions such as these to the DSPdimension
> forum at http://www.surroundsfx.com/forum as I am not sure whether or
> not the moderators here would consider them to be OT.
There is a dedicated developer list for those who develop Max externals:
dev@cycling74.com which should fit this as perfectly OT (read On Topic
in this case... ;-)
And I'd ask David Zicarelli if he would be willing to equip you with a
full Max license in return for a free Dirac LE pitch shifter...
It sounds interesting at least, could be even possible to sell a non LE
version then...
Just as an additional alternative for pitch shifting it would enhance
the value of Max for everybody...
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
Thing is that while it might not be a big problem to get a NFR version of Max/MSP (Cycling74 and Prosoniq have been swapping NFRs before) I simply don't have the time to work on it right now. I stand by my offer to help anybody who wants to do it in any way I can, but with the 3 jobs that I have already I can't work on more free stuff attm ;-)
And no, we can't make a commercial version. The company I work for is strictly into b2b custom software development. We're rather small and don't have the support power that would be required to provide adequate support for the kind of audience that you get when developing end user products.
Best wishes,
--smb
Hi,
Just for record, "Octave Shifter 2" entirely based on smbPitchShift.cpp is available as an AudioUnit freeware plug-in.
It offers two fully vectorized kernels called "High precision" and "Low latency".
Cheers,
Philippe
Hi,
Here again, and just for the record, "Diatonic Shifter 2" is a pitch-shifter on a per note basis and whose the internal pitch-tracker is entirely based on smbPitchShift.cpp, available as an AudioUnit plug-in:
Tested in MaxMSP with the [au~] external by M.Norris.
For using it as fast as possible when playing an instrument, I suggest the following setting:
- In DSP Status:
"Sampling Rate": 44100 Hz
"I/O Vector Size": 128
"Signal Vector Size": 4
"Optimize": Off
- In "Diatonic Shifter 2":
processing: Low Latency
rendering: Low, meaning the FFT frame size at 1024.
I'd be glad to get your comments to help me in the improvement of this plug-in.
Cheers,
Philippe
>>
I stand by my offer to help anybody who wants to do it in any way I can, but with the 3 jobs that I have already I can't work on more free stuff attm ;-)
>>>
I wonder if you might consider publishing an article that describes the techniques you employed. This would have a longer lasting benefit, as then anyone who can write code would be able to read your article and then implement (and perhaps augment or improve) the process.
Regards,
Eric
Hi Eric,
if you're referring to the smbPitchShift code there's an article at the DSP dimension web site that explains it in detail (it is called "Pitch Shifting Using the Fourier Transform").
For DIRAC there's a PDF document and example code that explains and shows how to implement it in a host application. Both come with the DIRAC LE library that is available on the download page.
HTH, kind regards
--smb
> Hi Eric,
>
> if you're referring to the smbPitchShift code there's an
> article at the DSP dimension web site that explains it in
> detail (it is called "Pitch Shifting Using the Fourier
> Transform").
>
Thanks Stephan,
There are many excellent articles at your site:
> For DIRAC there's a PDF document and example code that explains
> and shows how to implement it in a host application. Both come
> with the DIRAC LE library that is available on the download
> page.
>
The example code appears to be an API to the library, thus the actual processing code remains hidden. Might there be an article available that describes the DIRAC process with the specificity of, say, the 1965 Cooley/Tukey article on machine implementation of the FFT?
Best Regards,
Eric
Thank you. The actual site is at http://www.bernsee.com, The DSP Dimension is just a subdomain of that site.
> The example code appears to be an API to the library, thus
> the actual processing code remains hidden. Might there be an
> article available that describes the DIRAC process with the
> specificity of, say, the 1965 Cooley/Tukey article on machine
> implementation of the FFT?
No I don't think that this is very likely (or relevant for its usage, for that matter).
Kind regards
--smb
>
> No I don't think that this is very likely (or relevant for its
> usage, for that matter).
>
Thanks, Stephan. Your last point is certainly true. I wonder if any technical advances embedded in the software will ever become part of the general computer music research base (as did the FFT and wavetable lookup oscillator), or will rather remain locked behind applications software indefinitely.
Best,
Eric