On June 24, 2013 11:48:37 PM Florian Jung wrote: > Am 24.06.2013 23:32, schrieb Tim E. Real: > > On June 24, 2013 10:46:01 PM Florian Jung wrote: > >> what's this spos for? > >> > >> Is it a offset in the wavefile (i.e. equivalent behaviour would be to > >> cut away the first frames of my wavefile?), or is it more? > > > > Yes it is a sample offset into the file, where the wave should start. > > okay, thanks. This will wander into AudioStream, btw. > > > Ultimately my efforts at automatic latency correction could negate > > the need for this new spos user component. > > But yet, we still may need it because we actually do not have any other > > way for the user to precisely *manually* adjust the position of a wave > > part > > in samples. So I may have to do this anyway. > > uuuuh, latency. We'll need to reconsider that with the AudioStreams > anyway: Time stretching, and to a certain degree even sample rate > converting, introduces a bit of latency. Since no data is coming "live" > at this point, we can easily "shift" the playback of AudioStreams > appropriately internally, so it won't be a issue. But we need to think > about it.
Yes on playback we should always be able to compensate. > I think that AudioStream will have a getTotalLatency() function, a > getRecordingLatency() and a (GUI-driven) setRecordingLatency(). > > recordingLatency will be any user defined value to compensate for > whatever latency he knows about. > > and totalLatency will add some stuff because of the rubber band > processing to that value and return it. > > > Everything playing back stuff using AudioStreams must respect this > totalLatency() then, and appropriately initate playback a bit earlier. > > Does that sound sane? Just a thought. Agreed. That's what I had in mind for each audio node (track). A reported latency value and a user additional value. Latency is a very tricky subject especially with MusE. I hesitate to bring it all up here but there are very tough issues including monitored vs. recorded signals, record latency vs. playback latency, send/return loops (Audio Out -> Audio In), and separate unique signal path latencies vs. global use lowest path latency. I hope to address some of this stuff later. I read some apps have options, such as for that last point, and we're probably going to need some too. > > You once asked why our event time members are unsigned. > > I now think this may have been a bad idea, because we can't place or > > > > adjust events to before 'zero' time (negative position). This would be > > really useful for example the user could nudge a wave part to the left > > slightly, into negative start time < 0. > > > > Flo, if you decide to change event times from unsigned to signed, which is > > > > tedious but you have my blessing, try to replace the type with a common > > system-wide typedef of our choosing (call it Event_Time_t or something) > > so that we can easily manage it in the future :) > > I plan to remove most, if not all occurrences of frames. Times will be > in (x)ticks. Everywhere. I want audio and midi to line up always. > > >> And Tim. you have recently added sample-exact placing of wave events. > >> How did you do this? Which member variables are involved? > > > > Mm, no not really, not from a user graphical standpoint. > > That's where spos and proposed user component would come in. > > Unless your XTicks solve all these issues? > > I think they will. If you quickly summarize those issues for me, I can > tell you exactly whether it solves them all ;) As long as we have the ability have MusE split or chop or edit some wave part down to an exact frame, even if we haven't implemented it graphically yet, I'm happy. There was a feature request for frame-level positioning and editing, I hope we can honour at least the positioning somehow. Tim. ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
