Dirac Timestretching anyone?

[quintosardo]

Wow, this thread starts to be interesting

jackle&hide:

(seriously, absolutely no irony and no sarcasm in this message )

- Why did I write here: because the first message is from Tahome asking: is there somebody who wants to make a vst using this technology? I looked at the website and I didn't find ANY sound example, Tahome didn't say that he tested it, so it was like somebody asking for "anything similar to what the author is describing there"...

- Why did I write here, in "Development" forum: "Traks" is my first attempt to build a good time-stretching (and, as a collateral effect, pitch shifting) software. Some potential users tested it, comments are like "why there aren't three or four mixer with different colours?", "there will be a AU version?". Just joking, this is to say that a developer talks about far different aspects about a sw. It is a different point of view.

- If I look at click counters for threads, I ask myself: "Why ever should I advertize in developers section and not in instruments???"

- Why should I advertize for developers???

- "Traks" is (will be) free, like everything sw on that website. I'll try to sell hardware and samples. And if you know how cheap is that banner over this forum, how can you think that I would advertize here ?

- Why didn't I describe what I was talking about (code snippets, etc) ? What I meant was: "Is there anybody interested in testing and discussing about something else that could be similar? If yes, let me know that I go on here, otherwise sorry for posting out of topic"

- All this said because you made me look not as a spammer, but as a stupid spammer who spams in the wrong place to the wrong people and to sell absolutely nothing

But I agree that spammers should be executed, not simply fired... (seriously)

********************************

Now I try to write better what I meant.

I see here that you are developers interested in timestretching (I didn't find sound examples on that website, so I guess that the interest is not in that particular product but in anything similar). I've developed my first algorithm. I describe it shortly here:

I used an hybrid of modified SOLAFS (time domain) and look-forward frequency analisys.
I've tested it with ten tracks recordings and I feel it works very well for drum loops. Still not tested on other kinds of material but I believe that it will be only a matter of parameter settings.

I believe that speaking about an algo without testing its performances before makes no sense, so, if interested, I can provide a good demo. Then I can go inside the algorithm, but only if you (who, being developers, have a more "technical" hearing), feel that it can be interesting.

I prefer to avoid publishing the direct link to the demo here, because it uses audio material that isn't my property (it has been provided to me only for demo purposes), so I'll send it by mail or pm, instead of spreading it.

******************************

Sorry for the verbose post, now I go to write 100 times on the blackboard:
"I must improve my english, I must be more clear..."

[useruseruser]

Now you are really wellcome!

[pHz]

Sorry for the verbose post, now I go to write 100 times on the blackboard:
"I must improve my english, I must be more clear..."

only if J&H writes 1000 times ...

"i MUST remember this ISNT my personal forum"

slainte rob

[duncanparsons]

..nah, we know that, rob..

it's yours!

;)

DSP

[tahome]

I looked at the website and I didn't find ANY sound example, Tahome didn't say that he tested it, so it was like somebody asking for "anything similar to what the author is describing there"...

No there are no audio examples but there's a demo project that you can use on your own sounds. Of cousre I tested it (I said that earlier), with Xcode 2 on the Mac (came with the Tiger OS and it's a matter of altering a number and pressing the "Make+Run" button).

I got an email from Stefan today telling me that he still couldn't answer all the emails he got but he's working on a demo application that loads sound files for realtime processing with DIRAC. I'm very much looking forward to that as it will be a free, real-time time stretch and pitch shift application... so no need to make a VST and bother with the intricacies of the buffering you've mentioned earliert, I guess.

--th

[useruseruser]

I am pretty sure he will change something in the DIRAC code therefore ...

[tahome]

I don't know, maybe he will. But I (as an amatuer) can't see what would need to be different if he writes to the sound output instead of a file... I guess.

--th

[useruseruser]

No.
This is merely for pitch shifting possible.

Because a stretched sound is infact either shorter or larger than the original block of sample data, to f**k.

So a "real time stretching" (as you wrote in your post) is absolute NONSENSE. I did explain that again and again here for you, but you prefer to not to accept that fact. I really wana see that "realtime time stretching" software ...

I got an email from Stefan today telling me that he still couldn't answer all the emails he got but he's working on a demo application that loads sound files for realtime processing with DIRAC. I'm very much looking forward to that as it will be a free, real-time time stretch and pitch shift application... so no need to make a VST and bother with the intricacies of the buffering you've mentioned earliert, I guess.

[tahome]

Why is that?? As I read the DIRAC.pdf file, the output is always contiguous and the input is read via a callback (?) as needed. What would prevent anyone to do that during playback of a file?

[Mike from reFX]

Oh my god. So you want to time-strech realtime audio? How about an experiment: you catch a ball before it's thrown... Doesn't work? Man, you can't time-stretch what isn't there. It's impossible.

[useruseruser]

Right. Realtime is not playing a file. Realtime means. putting sound in and getting it out at same time (or extremely short latency) (like singing with a mikrophone passing thru an effect...)

What you mean, is never the less and basicly offline file processing. That is quite a difference to realtime. Even time stretching inside a host is highly complicated, when even possible in realtime (I donno any host, which performs that...).

BTW: some of the high quality algorithms needed in my tests soo much time to calculate, that any acceptable quality could ALSO not be achieved when processing it "realtime".

If the entire file is known, before any output occurs, so it is in fact offline processing.

[tahome]

Oh my god. So you want to time-strech realtime audio? How about an experiment: you catch a ball before it's thrown... Doesn't work? Man, you can't time-stretch what isn't there. It's impossible.

Why not - it's all there! I'm talking about real time time stretching a FILE, unless you can't read.

[useruseruser]

Sorry, but: "realtime stretching a file".
What NONSENSE is that

So I ask you, what that program does at current state?

(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...)

[tahome]

Right. Realtime is not playing a file. Realtime means. putting sound in and getting it out at same time (or extremely short latency) (like singing with a mikrophone passing thru an effect...)

Here's something from a similar discussion on realtime time stretch/pitch shift on the OSXaudio.com forum in case this helps:

I think you're mixing up the terms "realtime" and "full duplex" here.

"Realtime" just says that you can process the signal while you're shuffling around the data (for example, you can process the contents of a file while you simultaneously play back the result). More precisely, "realtime" implies that the processing is taking less time for a given chunk of data than the playback of that chunk.

In order to change the time base of a signal in a playthrough (ie. "full duplex") context you need to be able to control the rate of both the input and the output (that's what I was referring to in my last post when I said "as long as you have control over both the in- and output rate..."). IOW, when slowing down audio you have more samples at the output than you had at the input. When speeding up things the opposite is true.

You can do this for a "live signal" just as well - provided you can have a different sample rate for the input and output streams.

--smb

I guess that clarifies the matter. At least, it does for me.
--th

[Mike from reFX]

I'm outta here.