"Artist"? I thought we're talking about a Schlager music company here... an artist is something else.
If you have control over that domain you're involved in this company. So in fact I didn't involve them - you did! I don't care how you're affiliated, I think I've seen enough to know what to make of your judgements...
But as duncanparsons said - let's drop it and continue with the more productive things. That's fine with me - I don't care if you're Heino or some other freak (we too have plenty of them in Switzerland, which is where I live). But I do care about Dirac, because I'd like to see a product that uses it.
And if you don't like the discussion (or me, which you must feel perfectly free to do) simply don't post. We don't need a troll. We do need constructive input and great products, not nay sayers!
--th
Dirac Timestretching anyone?
-
- KVRian
- 1325 posts since 1 Sep, 2004
Well, that shows it all ... 
("Schlager music company"... I did NOT even know, that something similar exists... )
("Schlager music company"... I did NOT even know, that something similar exists...
)-
- KVRian
- 1325 posts since 1 Sep, 2004
OK, back to the topic.
Did someone find a workaround for the callback thingy used in realtime block processing mode (like a VST plugin) ?
Did someone find a workaround for the callback thingy used in realtime block processing mode (like a VST plugin) ?
-
- KVRian
- Topic Starter
- 568 posts since 20 Nov, 2003 from Basel, Switzerland
Like I said, they're not. I'm getting much better results if I set lambda to 3 and quality to "good", and 200% and 50% are by no practical standards a good way to evaluate the quality of a time stretching. 90% and 130% are more like what you would be using for a song.jackle&hyde wrote:Listen to that samples I posted above. They are constuctive enuff.
That's interesting, because I was thinking the same thing about you... Besides, I would expect someone who has no life to not have any "real life" problems at all... except a defective modem perhaps...jackle&hyde wrote:You hateful dude, (not being able to do a "normal" discussion and not able to live with other peoples opinion.)Probably you are even one of those guys, who spend too much time infront of their computer, loosing any ability to solve "real live" conflicts in any normal fashion.
Again, let's drop it. I'll download some Schlager now to listen to, and if my brain is soft like a marshmallow I'll report back here
Now back to work: wasn't duncanparsons suggesting a good way how this could be done in VST?
--th
I'm the stereo chancellor
-
- KVRian
- 1325 posts since 1 Sep, 2004
Ah, yes I did see now. I was totally confused by the men endless bashing on me...
Meight be that is sound more dangerous than it is (the callback thingy). But I personally couldn't live with a somehow "undefined latency issue".
Because this actually would be very difficult to implement VST "delay compensation" ...
I mean, delay compensation works merely with a well defined amount of delay and at initialization time of the plugin.
But the several quality modi may produce very different behaviour regarding that. I dunno.
Before I try it, I would like to collect some more informations and opinions and so on.
Finally (in my opinion) the entire try to implement that DIRAC into a realtime VSTi woud generally introduce a latency issue, which is simply needed to prevent some wrong pointer access and other accessing and synchronisation things.
Of course, that's all about pitch scaling aka shifting. Because time stretching is not possible with VST, unless you do it a kinda "pseudo offline" by precalculating some buffers.
But you cannot access (in the sense of change) blocksizes nor tempo of a VST host application or a single track. This makes realtime time stretching for entire VST tracks impossible, of course ...
But a "premapping" thing similar RePhrase or Intakt could we possible. Assuming you licensed the Professional license. Because only there you have all possible sampling rates supported and the so much "needed" formant adjusting available...
Meight be that is sound more dangerous than it is (the callback thingy). But I personally couldn't live with a somehow "undefined latency issue".
Because this actually would be very difficult to implement VST "delay compensation" ...
I mean, delay compensation works merely with a well defined amount of delay and at initialization time of the plugin.
But the several quality modi may produce very different behaviour regarding that. I dunno.
Before I try it, I would like to collect some more informations and opinions and so on.
Finally (in my opinion) the entire try to implement that DIRAC into a realtime VSTi woud generally introduce a latency issue, which is simply needed to prevent some wrong pointer access and other accessing and synchronisation things.
Of course, that's all about pitch scaling aka shifting. Because time stretching is not possible with VST, unless you do it a kinda "pseudo offline" by precalculating some buffers.
But you cannot access (in the sense of change) blocksizes nor tempo of a VST host application or a single track. This makes realtime time stretching for entire VST tracks impossible, of course ...
But a "premapping" thing similar RePhrase or Intakt could we possible. Assuming you licensed the Professional license. Because only there you have all possible sampling rates supported and the so much "needed" formant adjusting available...
-
- KVRian
- Topic Starter
- 568 posts since 20 Nov, 2003 from Basel, Switzerland
If I came across rude I apologize, I felt like the one being attacked. But let's put that aside now.
I think your suggestion sounds excellent: I've not seen a pitch shift or time stretch without a latency so I don#t see this as a problem. And I know the DIRAC.pdf speaks of an arbitrary number of frames, but wouldn't that (in your opinion) boil down to a small number of frames in practice?
--th
I think your suggestion sounds excellent: I've not seen a pitch shift or time stretch without a latency so I don#t see this as a problem. And I know the DIRAC.pdf speaks of an arbitrary number of frames, but wouldn't that (in your opinion) boil down to a small number of frames in practice?
--th
I'm the stereo chancellor
-
- KVRian
- 1325 posts since 1 Sep, 2004
Actually, the way the statement inside the documentation is formulated, it is not possible to achieve any control over that.
But that's a thing, which has to be tried out, or to see the source code (or ask the author) or whatever, to get informed how that finally is meant or managed. You know, you only get the binaries with DIRAC LE...
You probably have (again) no knowledgement about how a realtime processing audio opcode works. Nor do you even know, how PSOLA and FFT - also latency dependant opcodes - (used inside that framework) normally work...
(The documentation says "without any latency at the output". Well. That means for offline processing, not for realtime processing. Else the author would be a "wizzard" actually - and surelly earn the "Math Nobel Price" that way.)
Usually the number of frames to process inside a VST plugin must EXACTLY known. For input and output. That's an absolutely time synchron process. But the DIRAC obviously don't support that directly. It is intented for offline processing.
With realtime processing, an undefined behaviour of that sort actually requires an internal buffering mechanism. Then it lies in the hands of the implementor to manage that all...
But it is also absolutely unknown, how many (which maximum size) that mechanism must have, because there is nothing documented, you know.
If I implement my own PSOLA or FFT, I actually HAVE absolute control over that all. DIRAC actually hides that to us developers (making control over realtime block prosessing ala VST impossible or at least cumbersome and dangerous) ...
In simpler words: DIRAC actually decides itself, how many samples it takes from the input. That makes the entire process so complicated.
In realtime processing that amount is defined by the host application exclusively and HAS TO BE ACCEPTED WITHOUT ANY LIMITATIONS by the rendering process. What comes into has also finally to come outa, you know...
Therefore I'm interested in that theme. But I also currently haven't the time to do "self made tests" in the manner of "trial and error" whith a library, that's not my own work.
But maybe I am entirely wrong.
Nor do I actually know, what the Professional Edition costs and what licensing it has. I merely built and tested that included console application.
And maybe I am just too bussy with "Schlager Music"...
But that's a thing, which has to be tried out, or to see the source code (or ask the author) or whatever, to get informed how that finally is meant or managed. You know, you only get the binaries with DIRAC LE...
You probably have (again) no knowledgement about how a realtime processing audio opcode works. Nor do you even know, how PSOLA and FFT - also latency dependant opcodes - (used inside that framework) normally work...
(The documentation says "without any latency at the output". Well. That means for offline processing, not for realtime processing. Else the author would be a "wizzard" actually - and surelly earn the "Math Nobel Price" that way.)
Usually the number of frames to process inside a VST plugin must EXACTLY known. For input and output. That's an absolutely time synchron process. But the DIRAC obviously don't support that directly. It is intented for offline processing.
With realtime processing, an undefined behaviour of that sort actually requires an internal buffering mechanism. Then it lies in the hands of the implementor to manage that all...
But it is also absolutely unknown, how many (which maximum size) that mechanism must have, because there is nothing documented, you know.
If I implement my own PSOLA or FFT, I actually HAVE absolute control over that all. DIRAC actually hides that to us developers (making control over realtime block prosessing ala VST impossible or at least cumbersome and dangerous) ...
In simpler words: DIRAC actually decides itself, how many samples it takes from the input. That makes the entire process so complicated.
In realtime processing that amount is defined by the host application exclusively and HAS TO BE ACCEPTED WITHOUT ANY LIMITATIONS by the rendering process. What comes into has also finally to come outa, you know...
Therefore I'm interested in that theme. But I also currently haven't the time to do "self made tests" in the manner of "trial and error" whith a library, that's not my own work.
But maybe I am entirely wrong.
Nor do I actually know, what the Professional Edition costs and what licensing it has. I merely built and tested that included console application.
And maybe I am just too bussy with "Schlager Music"...
-
- KVRian
- 1325 posts since 1 Sep, 2004
So? And what are YOU then?
-
- KVRist
- 89 posts since 27 Oct, 2004
kudos to stephan berntsee for putting this out. i wish the free, open source project had worked out, but i understand his reasons and i'm glad he's released a free .lib anyhow.
as far as i can figure out from the docs, to process a certain number of samples you pass that number and your output buffer to DiracProcess. Dirac then requests blocks of unpredictable size till it's got all the data it needs. but i guess it's safe to assume that for pitch-shifting at the same playback speed it's not going to ask for more input than you need output (though you would i guess check for this and zero pad if it did), even if it wants it in odd-sized chunks.
That sounds usable enough for real-time VST pitch-shift, a bit more fiddly than just passing a buffer and a blocksize, but not much. i'll be surprised if someone hasn't released a plugin by the weekend.
or have I missed something?
as far as i can figure out from the docs, to process a certain number of samples you pass that number and your output buffer to DiracProcess. Dirac then requests blocks of unpredictable size till it's got all the data it needs. but i guess it's safe to assume that for pitch-shifting at the same playback speed it's not going to ask for more input than you need output (though you would i guess check for this and zero pad if it did), even if it wants it in odd-sized chunks.
That sounds usable enough for real-time VST pitch-shift, a bit more fiddly than just passing a buffer and a blocksize, but not much. i'll be surprised if someone hasn't released a plugin by the weekend.
or have I missed something?
-
- KVRian
- Topic Starter
- 568 posts since 20 Nov, 2003 from Basel, Switzerland
I don't know but that sounds good to me (as an amateur). Btw. version 1.01 is available now, obviously there have been some problems with crashes in 1.0...
--th
--th
I'm the stereo chancellor
-
- KVRian
- 1325 posts since 1 Sep, 2004
I wrote the author. He said, that he will update the website with all price and license information.
That was 3 days ago.
Probably he is currently fixing the numerous bugs people have discovered with the free LE version.
That was 3 days ago.
Probably he is currently fixing the numerous bugs people have discovered with the free LE version.