On February 6, 2013 12:04:46 PM Florian Jung wrote:
> Am 06.02.2013 10:01, schrieb Tim E. Real:
> > Basically a disk helper thread that fetches the wave data via SndFile
> > several blocks into the future, reset upon seek of course.
Correction. Reviewed, looks like it is one segmentSize block at a time,
but can be /backlogged/ several blocks
The thread is for decoupling the call from here in audio thread:
Audio::process() { ...
MusEGlobal::audioPrefetch->msgTick();
... }
to here in the prefetch thread:
AudioPrefetch::prefetch() { ...
track->fetchData(writePos, MusEGlobal::segmentSize, bp, doSeek);
... }
which calls Event::readAudio() and so on down to the SndFile read.
> > It is a (the?) perfect place to interject /specifically/ with realtime
> > converter processing.
Was thinking about that...
It's a good place for static ratios such as constant samplerate conversion
or constant tempo change.
(Are you planning samplerate conversion? That's what I have ATM using SRC.)
But I'm not sure about dynamic tempo streams like midi clock or MTC.
We might need to work out a "hard real time" method, as you call it,
for tighter locked-loop control.
Man, when you're doing syncing you need the tightest locked-loop.
May even need something similar to how I did the sample-accurate
audio controller stuff (by breaking up each process cycle into
plugin 'runs' if required, to match the changes in the controller streams).
I'll review some more.
You mentioned one library has ratio maps or something?
That'd be a game changer.
> > And I wasn't about to go ripping up the complete design of clones which
> > already took soooo much of my time to understand and get fixed
> > in the first place.
>
> heh, maybe this was the reason for clones taking sooooo much time ;)?
> really, usually that's a sign of a bad design.
I know you are just making light, but excuse me, respect please.
I don't think Werner could have foreseen that devs would be planning this
over a decade later. Probably since audio support didn't exist at the time.
This is nothing wrong with clones. They are simply showing a deficiency
in regard to this /new/ usage.
When I discovered them they were surprisingly near-complete but
not even exposed to the user until I brought them into the forefront.
Do you have any idea how long that took me to understand at the time?
[Snip from next message in thread]:
> if you have a song which gets faster and faster, and you have recorded
> some guitar on the beginning of your song, then you want to be able to
> move this event and adapt to the new tempo at the new position.
> or you might want to import any wave file and move it to arbitrary
> positions without affecting the rest.
>
> do you understand why we need so individually stretch every event?
No.
Because the 'intrinsic' tempo map that we will store with a wave
will be static and will never change unless the user re-taps or clears it
or re-draws it on some special graph or whatever.
Every wave event using that wave, no matter where its position, only needs
that intrinsic tempo map, to compare with the global tempo map and apply
the differences back to the converters.
That goes as well for even shared wave events in clones and non-clones.
And moving a wave event around does not change its intrinsic tempo map.
So the only missing piece of the puzzle was knowing which part and its
position, containing the wave event.
So that's why I went with a simple mapper, bringing in the converter as well.
Why redesign?
A clone is a clone is a clone. In theory it should be identical in all
respects meaning the same pointer can suffice.
If clones were separate but identical lists what you'd have there is a
whole lotta redundant identical event data just for the sake of supposed
different intrinsic tempo maps.
At that point they could not be called clones.
They would be called 'links' to other parts.
Now, having said all that, your idea has interesting merits, I'm not
dissing the idea completely.
For example de-cloning a part would simply mean removing its 'link'
to another clone and immediately we have two separated free parts
with complete event lists.
Cloning a part would simply mean selecting two parts and it assigns
the events from the first part to the second, and then creates the 'link'.
And class Event + kids themselves do not really take up a lot of memory,
per se, but it's just the principle of the thing - a lotta redundant events
and in the song file and so on.
Still, I do not believe it absolutely necessary to do this very major change.
Unless you can convince me some more...
> depends what you consider as "realtime":
> "hard realtime", like the audio thread: yeah, i do not intend that
> stretching works that way.
>
> "dynamically prefetch the data for the next 500ms or so": i'm doing that.
>
> you, with few RAM but a strong CPU might want to tell MusE "please do
> not waste my RAM with all this; just pipe the waves through a stretcher
> every time i play it."
>
> me, with lots of RAM/disk space but a weak CPU will tell MusE: "please
> use memory. Do the stretching one time, store that result in RAM or in a
> file, and then never bother my CPU with that again (except i move the
> event or change the tempomap)".
>
> both will be possible.
I don't understand. The first part is what I've been trying to tell you about.
Realtime, non-offline processing.
It sounds like our prefetch cache but with a longer time.
You said realtime was bad. Now you're saying you will support it?
Is there a contradiction in the third next paragraph?
> > How are you going to sync waves to a tempo stream instead of a map?
> > Such as Jack Timebase, external midi clock, or MTC time code?
>
> but how do you want to stretch it in real time then? you'd need to know
> in advance when the next clock signal will occur (which you don't know).
> and because you cannot look into the future, you will have to readjust
> again and again. but you cannot readjust in RT mode, because you don't
> exactly know whether the stretcher has used your desired ratio of 0.9,
> or if it maybe used 0.8999999, due to the way these stretchers work.
> errors would accumulate then.
>
> my whole idea was taylored around the "offline mode" of such a
> stretcher; even if we calculate the data "just in time", the stretcher
> as a frame2frame-map and is offline.
> which IMHO is the best solution, as long the tempo master comes from
> MusE. can you agree with that?
>
> real time processing for external clocks... i honestly have no idea
> about external clocks, how they work, how they are used within MusE etc.
> and no idea how we could sync any time stretcher, even in real time
> mode. do you have one?
I don't claim to have all the answers, experimentation will be required,
but I believe it is possible to have reasonable sync.
Syncing is often not a perfect thing - a game of cat and mouse.
Often perfectly locked sync is not possible, but close.
The target is constantly trying to 'chase' after the source.
Thus the common term "chase-lock" rather than just "lock".
Starting with time code:
-----------------
For hope and inspiration I give you... Ardour:
Ardour claims to have one of the best Midi (Linear) Time Code + audio
sync around.
http://rg42.org/wiki/a3syncmanual
That says Ardour uses vari-speed (stretching) to sync to timecode.
Jack Timebase:
------------------
This would be similar but easier as these are always-readable
tempo/sig values.
However it is not a perfect solution, the advanced features available for
accuracy are not used by very many apps and some incorrectly, destructively
(Jack Timebase is a piece of memory shared by all the apps using it!).
My survey when I began to add this Jack-Timebase-Drives-Midi stuff to MusE,
was not very encouraging.
External Midi Clock:
--------------------
Yeah, well, this is the ugliest of them all.
Very hard to re-create a smooth running tempo value from such a jittery clock.
However, if we just apply what we see arriving verbatim, jitter and all,
to the converters, this is the most accurate sync we can hope for.
I'll think some more about it.
When I added external clock tempo recording recently, I allowed this
type of accuracy. As well as less accurate but very smooth filtering.
Tim.
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Lmuse-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lmuse-developer
