From: Tim E. R. <ter...@ro...> - 2013-02-24 09:29:46
|
If you have never used this setting, don't use it yet until I fix it, and ignore the rest of this message. Oops. It was a bad idea to expose that value to the user. I mean it works, allowing you to compensate for recorded latency. Until you *split* the wave part - then it messes with that number, the number becomes very high, but at least it keeps any original component you had dialed in before splitting. The good news is I'm going to try to correct this problem. The bad news is it will *not* be possible for me to automatically and silently convert existing songs, like I usually do, to use the newer system. The value I exposed will now have to be hidden again. Instead, you will do this adjustment in *another* place, see below. The good news is that your songs will just work still. They'll use the value that was stored and will play as you left them. The bad news is I won't even be able to allow you access to the value to see what you might have dialed in. You'll have to examine the song file Wave Event for these offset positions and kind of guess at what you might have set it at, and either leave it alone or *subtract* it and re-enter it in the new place. That's easy for wave parts which you didn't split - you'll see your original dialed-in value like 256, 512, 1024 etc. Not so easy for parts which you had split - you'll see high numbers, and your original value is 'lumped in' with the split point ! So it's impossible for me to automatically tell what to do there, for correcting songs. Apologies for inconveniences here. But seriously, if you have trouble send me the song file after I have hopefully fixed this problem and I'll try to correct it for you. To devs: ------------- Instead of of fooling around with the WaveEvent _spos value, my plan is to add a new offset value directly to class SndFile. The value will simply be added to all positions. Simple as that. I figure after all, this value should apply to the wave and all usages of it, not on a per-event level like I was attempting. The user will access and adjust this new value via... drum roll please... The Clip List Editor ! Now here's the thing that I need to inform you about: I need to add a *new* section to the song file: "Waves" (or "Clips"). It will likely appear in the Song section just before any tracks. The neat thing is that it will populate the sound file list before any tracks reference the waves (so that I can set this *new* value on them, just once and only once). Thus it will simply 'pre-load' the waves, no *harm* done. Normally the first reference to a wave found in a track, is what causes the wave to be loaded. Here however, I'll simply load them beforehand. Sooo, just an advance warning in case it'll cause headaches for anyone. Particularly Florian's new branch might be sensitive to these changes? Yeah, all this just for basic latency compensation. Trust me I've said I really want to put a true sophisticated automatic system in there but man, it is sooo complex and has tough paradoxes for example dealing with plugins etc. Can't explain right now... Anyway just gimme a holler with any concerns. Thanks. Tim. |
From: Florian J. <flo...@gm...> - 2013-02-24 14:24:10
Attachments:
signature.asc
|
Am 24.02.2013 10:28, schrieb Tim E. Real: > If you have never used this setting, don't use it yet until I fix it, > and ignore the rest of this message. > > Oops. > > It was a bad idea to expose that value to the user. > > I mean it works, allowing you to compensate for recorded latency. > Until you *split* the wave part - then it messes with that number, > the number becomes very high, but at least it keeps any original > component you had dialed in before splitting. wouldn't it possible be better to finalize the subticks? they would be added sooner or later anyway, and will fix this problem (more intuitively, as i think.) sure, there needs to be done a lot (saving, loading, fixes), but i that's not impossible. just a thought g flo |