Dirac Timestretching anyone?

[useruseruser]

Me too.

[tahome]

It would not even possible to play back the (high quality mode) result in realtime with DIRAC. Because that code is definately much too slow to perform that...

Processing of a 10 second file with kDiracLambda3 and kDiracQualityGood takes about 2 seconds on my G5/2GHz with Xcode 2 and the quality is superb. So I guess it could operate in realtime just as easily. Problem is, I don#t have a C compiler for my PC so I can't test it on Windows. But I don't think it should be much slower than the G5...

[tahome]

I'm outta here.

Yeah, be my guest and do it the easy way if you don't wanna admit you don't have a clue. I'll better wait for the demo program from the pro instead of making the same mistake twice and asking the bunch of ignorants here for help.

Whatever.

[duncanparsons]

I'm outta here.

Yeah, be my guest and do it the easy way if you don't wanna admit you don't have a clue. I'll better wait for the demo program from the pro instead of making the same mistake twice and asking the bunch of ignorants here for help.

Whatever.

ummm... lets just do a quick review of posts..

I'm off too..

DSP

[useruseruser]

Maybe a better way to find a "serious" finish of that topic here:

(From the developer to all suscribers to the long awaited official clarification.)

Code: Select all

Hi,

thank you for your interest in my web site.

I'm sorry but due to the overwhelming interest in DIRAC I'm presently  
unable to keep up with the email traffic. Here are a few answers that  
I've compiled from the questions I'm presently getting. If your  
question isn't covered please bear with me, I will address all other  
questions as soon as I can.

Q: How much do the STUDIO and PRO version cost?
A: I'm presently putting together a web page with pricing information  
on two different licensing types. One involves a one-time payment,  
the other one is based on a yearly fee. Both are independent of the  
number of copies of your software that are sold and on their pricing  
structure. Please note that I cannot provide DIRAC on a per-copy  
licensing fee (royalty) basis, as it would be impossible for me to  
track and verify the number of copies of every piece of software that  
is using it.

Q: Will there be a Linux version?
A: Yes, I am working on a linux version at this time. I'm planning  
for compilation under Debian linux on x86 CPUs with other flavors  
upon demand.

Q: What will it cost to license source code?
A: There are no "general terms" for source code licensing. Licensing  
source code depends on what you intend to do with it and is therefore  
subject to discussion and further negotiation. The licensing fee is a  
one-time up-front payment and would depend on who you are and how  
large your user base is.

Q: When will the STUDIO and PRO versions become available?
A: STUDIO and PRO are planned for release in July 2005

Q: Is there any way to process the audio in a random-access manner,  
possibly even reverse playback?
A: Not yet, but I am working on an addition to the API that allows  
realtime non-sequential playback of audio for special effects  
(unlimited time stretching, reverse effects) and DJ applications.

Q: Evaluating DIRAC using the examples is a bit cumbersome. Do you  
have any other way of demoing the technology?
A: I am working on both audio examples and standalone demo  
applications on the MacOS and Windows platforms at this time. They  
will become available as a free download off the DSP Dimension web site.

Q: What about a 64bit Windows version?
A: A 64bit Windows version is currently being worked on. If you're  
interested in evaluating a pre-release version please contact me and  
I will send you the required prototype NDA as well as more  
information on the planned release of a 64bit version of DIRAC

Q: If I process my files using the demo projects I'm always getting a  
mono file as a result. What gives?
A: The AIFF file reader (miniAIFF) I am using in the demo application  
cannot write stereo interlaced AIFF files at this time. It will also  
always use the left input channel for its processing. This is not a  
restriction of DIRAC but rather one of the demo project which could  
easily be changed by duplicating processing to include two instead of  
one channel.

Q: I'm having problems getting DIRAC LE to run in realtime. What's  
the best setting?
A: Try using kDiracLambdaPreview in combination with  
kDiracQualityPreview for the fastest rendering. Quality can be  
further improved by using kDiracLambda3 in combination with  
kDiracQualityPreview or kDiracQualityGood if your target system can  
handle the load. I'm still working on optimizing DIRAC more, the  
initial 1.0 release was more concerned with quality than with  
performance so you should see an improvement with the next releases.  
As a ballpark number for the Mac platform, the fastest setting takes  
up about 26% for stereo processing and the better setting uses about  
38% CPU on a G5/2GHz Macintosh with MacOS X 10.4.1. I'm compiling a  
performance figure for the PC right now (there's a larger variance  
due to the greater variety in systems and CPU architecture).

Make sure you check out my NEWS page on http://www.dspdimension.com  
every now and then. If there are any news, this is where they will be  
published first.

Kind regards,

Stephan M. Bernsee
The DSP Dimension
http://www.dspdimension.com

[JCJR]

I emailed Stephan suggesting an ActiveX component version of Dirac, but he is so busy, it is doubtful that will happen anytime soon.

Maybe imagining a problem that doesn't exist, but DLL's made with MSVC can be difficult/impossible to load from Borland compilers. Since I mostly use Borland products on PC, if this is the case something would have to be done. Has anyone already tried loading the Dirac DLL from Borland C++ Builder or Delphi?

Have been too busy to mess with it, but if in fact this is gonna be a problem, probably the easiest solution would be to fire up my Visual Studio 7 (which I rarely use and am quite ignorant of), and make an ActiveX wrapper for the Dirac DLL.

If I try that, don't have time right now to turn it into a long science project. Can someone suggest a downloadable monkey-see-monkey-do sample project or easy step-by-step web tutorial on making ActiveX components in Visual Studio?

[LucaZ]

Maybe imagining a problem that doesn't exist, but DLL's made with MSVC can be difficult/impossible to load from Borland compilers. Since I mostly use Borland products on PC, if this is the case something would have to be done. Has anyone already tried loading the Dirac DLL from Borland C++ Builder or Delphi?

Here is the code i write to load dirac.dll using Borland C++ Builder.
Dynamic loading is used to avoid MS/BORLAND static linking incompatibility...
Also the function pointer are accessed via getprocaddress by ordinal instead of name...
(use implib to catch the ordinal of the functions)
that is because the funciona are mangled by MSVC compiler producing an artefact functionname

warning: at first try my placeholder user function just was returning 0 and it happended that my test app quits without any error message !!!
as i return > 0 it seems to work ok

// typedef function pointer
> typedef void *(*PDiracCreate)(long lambda, long quality, long numChannels,
> float sampleRate, long (*readFromChannelsCallback)(float *data, long
> numFrames, void *userData));
> typedef void *(*PDiracCreate2)(long lambda, long quality, long numChannels,
> float sampleRate, long (*readFromChannelsCallback)(float **data, long
> numFrames, void *userData));
> typedef void (*PDiracDestroy)(void *dirac);
> typedef long (*PDiracGetInputBufferSizeInFrames)(void *dirac);
> typedef long double (*PDiracGetProperty)(long selector, void *dirac);
> typedef long (*PDiracProcess)(float **audioOut, long numFrames, void
> *userData, void *dirac);
> typedef long (*PDiracProcess2)(float *audioOut, long numFrames, void
> *userData, void *dirac);
> typedef void (*PDiracReset)(void *dirac);
> typedef long (*PDiracSetProperty)(long selector, long double value, void
> *dirac);
> typedef const char *(*PDiracVersion)(void);
>
> //user function
> //---------------------------------------------------------------------------
> long diracReadData(float **chdata, long numFrames, void *userData){
> //your code.....
> return ...; //WARNING if my code return 0 my app quit otherwise it works
> }
>
> //---------------------------------------------------------------------------
>
> //load library
>
> PDiracCreate diracCreate=0;
> PDiracCreate2 diracCreate2=0;
> PDiracDestroy diracDestroy=0;
>
> HINSTANCE hdirac = LoadLibrary( "DIRAC" );
>
> if (hdirac){
> (FARPROC)diracCreate=GetProcAddress(hdirac,(LPCSTR)MAKELONG(1,0));
> (FARPROC)diracCreate2=GetProcAddress(hdirac,(LPCSTR)MAKELONG(2,0));
> (FARPROC)diracDestroy=GetProcAddress(hdirac,(LPCSTR)MAKELONG(3,0));
> if (diracCreate2){
> //void *dirac = diracCreate2(kDiracLambda3, kDiracQualityPreview, 1,
> 44100., &diracReadData);
> //diracDestroy( dirac );
> }

[JCJR]

Thanks very much Lucas!

[blümchen]

Did now someone actually invent that omnipotent revolutionary "DIRAC realtime time stretching plugin"?

[JCJR]

Did now someone actually invent that omnipotent revolutionary "DIRAC realtime time stretching plugin"?

As a realtime insert, if the plugin is slowing tempo, returning more samples than it is receiving, wouldn't either the host or the plugin need VERY LARGE sample buffering to store the extra data until it is time to play that extra data?

Do some hosts automatically determine that they will receive more (or fewer) samples than they send to a plugin, and auto-adjust the number of samples they send to avoid severe buffering problems? It sounds like impressive programming, since the play-pointer of the stretched track would be advancing at a different rate than the play-pointer of the other tracks.

I've written real-time playback stretching inside a program where the program knows what to expect. But hats-off to any folks who programmed their sequencers smart enough to effortlessly receive arbitrary-sized output data from each and every track insert plugin!

It might be pretty simple with a 'pull' model where the plugin or plugin's container asks the sequencer's file system handler for data when necessary.

[blümchen]

Did now someone actually invent that omnipotent revolutionary "DIRAC realtime time stretching plugin"?

As a realtime insert, if the plugin is slowing tempo, returning more samples than it is receiving, wouldn't either the host or the plugin need VERY LARGE sample buffering to store the extra data until it is time to play that extra data?

And what is then with speeding up?

[blümchen]

My "joke" was merely destinated to a certain person inside this thread, who claimed that this would be in fact possible with DIRAC ...

(Everyone, who actually has got a little bit brain, can actually see that a "real realtime stretching" of audio (in both directions) is pure nonsense. Because you can't (at least) look into the future - not currently - ...) But he obviously could.

.

[JCJR]

Was just 'seriously' wondering what hosts can handle a stretch or shrink condition coming from a plugin. I don't keep up with all the hosts, maybe lots of em can automatically do that.

For a long time Cakewalk shipped a rudimentary DirectX pitch/time plugin which presumably worked as expected in the Cakewalk sequencer. I simple-programmed my DX hosting to always expect same-sized input/output buffers (a 'push' model), and that Cakewalk pitch/time plugin would eventually misbehave and crash me. But that is just my laziness in not accounting for the possibility of different-sized in/out buffers in a realtime situation. Maybe lots of sequencers do the right thing?

[blümchen]

Whatsoever, there are two main reasons, why that cannot work with usual VST hosts:

1. You get merely streaming sample blocks from the host application with a certain size. The size of input has to match completely with the size of the resulting output.

There is no possibility to access an entire track with the current VST specification, nor is there a possibility to look ahead, what then comes next...

2. This all merely would work (if even supported) with already available (already recorded) audio material. But NEVER in realtime, like live playing of course. You cannot "look adead", what a musician probably wants to play.

Althought, it wouldn't make any sense to timestretch live playing, would it?

And the technology itselfes introduces generally a remarkeble LATENCY because the used frequency domain algorithms (FFT), which would make any realtime playing at least problematic. And the highest quality modes are simply too slow to perform in realtime never the less.

Even when merely used for common pitch scaling, then the latency would be a problem for live input.

[JCJR]

2. This all merely would work (if even supported) with already available (already recorded) audio material. But NEVER in realtime, like live playing of course. You cannot "look adead", what a musician probably wants to play.

Althought, it wouldn't make any sense to timestretch live playing, would it?

<snip>

Even when merely used for common pitch scaling, then the latency would be a problem for live input.

Yes, most methods of pitch scaling unavoidably involve some kind of built-in timestretching to keep the playback duration the same. It is difficult to do that except with at least some buffering and latency. Well, it is just generally difficult while preserving any semblance of audio quality, though some programmers have figured out how to get it done.

I have some sloppiness of terminology. Maybe there are accepted standard terms, dunno. When I hear 'non realtime', usually think of disk-based processing where the process can look ahead and behind, and take as long as it pleases to get the job done.

'Realtime', I usually mean doing a process on-the-fly during playback of already recorded material. A playback and plugin system could do this kind of 'playback realtime' time/pitch shift, but dunno how many plugin schema are capable of it. Thanks for the info that it is generally not possible with VST.

'Realtime playthru' is obviously not possible for time-stretch of live input, except with arbitrarily large buffering and delay.

Are there better generally-recognized words to descrube these three categories of processing?