On Wed, 10 Jul 2013 15:18:17 -0400 RJ Ryan <rryan-opwvymzfgylytjvyw6y...@public.gmane.org> wrote: > On Wed, Jul 10, 2013 at 3:06 PM, petah > <mixxx-356rgwljecpbdgjk7y7...@public.gmane.org> wrote: > > So the Javascript driver would keep up when called that often? > > > Depends on your hardware I guess? There's nothing that would prevent it > from running fast on fast hardware.
Ok. Are there mitigation measures (other than k-boom) in case js receives more messages than it can process? > > > Maybe you should allow Mixxx to set the update interval via a sysex > > > message? Currently Mixxx doesn't have a way of telling how loaded it is. > > > > That would be a useful addition. > > > Yea, there aren't many good methods though. CPU usage is too course since > if the scheduler is a good scheduler it can still schedule high priority > threads under heavy CPU usage (e.g. we should be able to analyze a track > (which uses a lot of disk/CPU) and play it at the same time). Underrun > count is an after-the-fact measure of things going badly but definitely a > good one to use to know when to back off. Maybe you could present a table with a bunch of variables to js, whether they're relevant or not, so drivers can toy with those in the meantime. F.ex. one could be a stop watch around Mixxx's frame processing code, another the percentage of time-scaler buffer filled. > It shouldn't matter unless we have a priority inversion issue (which the > engine used to have much more of). We're still working on getting rid of > some of the places that can cause things like this. Maybe that comment is > out-dated? If you do find that changing a control rapidly causes buffer > underruns could you file a bug and include repro details? Sure but I'm also running my low-level sample callback to decode the timecode so my report may not be relevant, though it used to run fine on a crappy HP touch-laptop running XP from years so should just be a CPU usage blip nowadays. > As Owen mentioned, controlling Mixxx via playposition is not meant to be > used in the way you're talking about using it. That's meant for seeking to > a new position. Every time you seek to a new position you are resetting the > internal engine state (e.g. the time and pitch scaler state gets reset > which throws away work since some scalers such as the soundtouch / > rubberband scaler have to do a significant amount of readahead). Right, time-stretching needs a fairly wide sample window. Maybe you could cache the last valid scaler state while a newer is still filling up? I.e. if the scaler needs N frames, on a "flow disruption" instead of resetting it right away, setup a frame countdown and use the old one in the meantime. F.ex. when doing a Cue Play the tempo is most certainly already known. AFAIK you can't adjust tempo/pitch during a cue loop because its period is determined by the redbook-adjusted CD "groove" position though more recent CDJs may behave differently. > The way > that vinyl control works is by controlling the rate. I agree with Owen -- > you should control the rate and not the position. Yeah but you're just passing the rate computation hot-potato onto to the driver / me :) I probably need even more frames than a time-stretcher to compute a stable tempo to make sure it's not some other user command otherwise I'd produce chaotic tempo values. I guess proof is in the pudding so we'll see. thx, -- p > > > > >You could just continuously write messages to Mixxx and then parse > > > > >them in a Mixxx MIDI script. > > > > > > > > > > > > > > >On Wed, Jul 10, 2013 at 1:43 PM, petah < > > mixxx-356rgwljecpbdgjk7y7tuq-xmd5yjdbdmrexy1tmh2...@public.gmane.org> wrote: > > > > > > > > > >> I had this idea for a high-resolution MIDI interface and would like > > to > > > > >> know if it's doable/stupid before implementing it. > > > > >> > > > > >> My (software) device continuously updates a few high-res variables > > at > > > > high > > > > >> speed, i.e. it's not strictly event-oriented. There are two CDJs, > > each > > > > has > > > > >> the following variables: > > > > >> > > > > >> - track (unsigned int) > > > > >> - position_ms (unsigned int) > > > > >> - tempo (signed float) > > > > >> - pitch-bend (signed float) > > > > >> > > > > >> to keep it simple let's say each variable takes 32 bits, so that's > > 64 > > > > >> bytes for both decks (and ignore other variables for now). > > > > >> > > > > >> if my software were to construct a MIDI SysEx message with this > > data as > > > > >> one binary blob, would a Mixxx javascript driver be able to query > > that > > > > blob > > > > >> to interface with my device? > > > > >> > > > > >> Since the data is real-time, Mixxx could query it as fast as it > > > > can/wants > > > > >> so there are no timing constraints on my end. > > > > >> > > > > >> thoughts? > > > > >> > > > > >> thx, > > > > >> > > > > >> -- p ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
