[Mixxx-devel] Traktor DJ playlist thumbnail decoder
Hey,
I no longer use Mixxx or other software-based mixing (at least for the moment)
but figured someone here may be interested to know the AudioID binary blob in
a Traktor DJ playlist's entry is actually a base64-encoded visual thumbnail of
the track's WAV, squeezed to 512-pixels wide, with each 4-bit nybble
representing a volume. The image is mirrored vertically. I guess it's used as a
preview while tracks are deep-scanned.
I attached my source here, the thumbnail decoder function is at the end,
nmlEntry::SaveWAVThumbnail(), the rest is rubbish.
cheers,
-- p
// Native Instruments' Traktor DJ NML playlist decoder
// #include regex // not supported until gcc 4.9 ?
// #include tuple
/*
- RELEASE_DATE is optional
*/
#include wx/filename.h
#include wx/base64.h
#include wx/wfstream.h
#include wx/txtstrm.h
#include wx/sstream.h
#include wx/regex.h
#include Controller.h
#include TraktorDec.h
using namespace LX;
using namespace std;
enum FIELD_TYPES : int
{
FIELD_ILLEGAL = 0,
FIELD_STRING,
FIELD_INTEGER,
FIELD_DOUBLE, // front space-padding is ok
FIELD_UNIX_PATH,
FIELD_FILE_NAME,
FIELD_OS_PATH,
FIELD_OS_VOLUME,
FIELD_DATE, // /MM/DD
FIELD_MARKER_NAME, // { Cue | Beat Marker | Fade In | Fade Out } or { first moan | aha! | beat start | beat restart | restart | buildup start }
FIELD_ENC64,
FIELD_STRING_LIST // for CUEs
};
enum TAG_TYPES : int
{
TTYP_ARTIST = 0,
TTYP_AUDIO_ID,
TTYP_ID,
TTYP_LOCK,
TTYP_TRACK_TITLE,
TTYP_DIR,
TTYP_FILE,
TTYP_PATH,
TTYP_DISK_VOLUME,
TTYP_ALBUM,
TTYP_TRACK_NUMBER,
TTYP_BITRATE,
TTYP_COMMENT,
TTYP_GENRE,
TTYP_IMPORT_DATE,
TTYP_KEY_LYRICS,
TTYP_LAST_PLAYED,
TTYP_PLAYCOUNT,
TTYP_PLAYTIME,
TTYP_RANKING,
TTYP_RELEASE_DATE,
TTYP_BPM,
TTYP_BPM_QUALITY,
TTYP_PEAK_DB,
TTYP_PERCEIVED_DB,
TTYP_LABEL,
TTYP_POS,
TTYP_TYPE
};
static
void ConvVal(const wxString s, wxString *val_s)
{
wxASSERT(val_s);
*val_s = s;
}
static
void ConvVal(const wxString s, int *ip)
{
wxASSERT(ip);
long l = 0;
bool ok = s.ToLong(l);
wxASSERT(ok);
*ip = (int) l;
}
static
void ConvVal(const wxString s, double *dp)
{
wxASSERT(dp);
bool ok = s.ToDouble(dp);
wxASSERT(ok);
}
static
void ConvVal(const wxString s, wxDateTime *dt)
{
wxASSERT(dt);
bool ok = dt-ParseDate(s);
wxASSERT(ok);
}
// CTOR ---
TraktorDecoder::TraktorDecoder(Controller *controller)
{
wxASSERT(controller);
m_Controller = controller;
m_PlaylistEntries.clear();
m_TagToInfoMap.clear();
#if 0
m_TypeToConvMap =
{
{FIELD_STRING, {ValToStr}},
{FIELD_INTEGER, {ValToInt}},
{FIELD_DOUBLE, {ValToDouble}}, // may be space-padded in front
{FIELD_UNIX_PATH, {ValToStr}},
{FIELD_FILE_NAME, {ValToStr}},
{FIELD_OS_PATH, {ValToStr}},
{FIELD_OS_VOLUME, {ValToStr}},
{FIELD_DATE, {ValToDate}}, // /MM/DD
{FIELD_MARKER_NAME, {ValToStr}}, // { Cue | Beat Marker | Fade In | Fade Out } or { first moan | aha! | beat start | beat restart | restart | buildup start }
{FIELD_ENC64, {ValToStr}},
{FIELD_STRING_LIST, {ValToStr}}, // for CUEs
};
#endif
// use ___(unique)___ (R)aw string delimiter to use double-quotes within, even if preceding a ')'
bool ok = m_EntryRE.Compile(R___(.*?ENTRY(.*?)/ENTRY)___, wxRE_ADVANCED);
wxASSERT(ok m_EntryRE.IsValid());
ok = m_FieldRE.Compile(R___(.*? ([A-Z_]+)=(.*?))___, wxRE_ADVANCED);
wxASSERT(ok m_FieldRE.IsValid());
// few duplicate tags despite XML hierarchy, except for
// labels (list)
// title (duplicate)
m_TagToInfoMap =
{
{ARTIST, {TTYP_ARTIST, FIELD_STRING}},
{AUDIO_ID, {TTYP_AUDIO_ID, FIELD_ENC64}},
{ID, {TTYP_ID, FIELD_INTEGER}},
{LOCK, {TTYP_LOCK, FIELD_INTEGER}},
{TITLE, {TTYP_TRACK_TITLE, FIELD_STRING}},
{DIR, {TTYP_DIR, FIELD_UNIX_PATH}},
{FILE, {TTYP_FILE, FIELD_FILE_NAME}},
{PATH, {TTYP_PATH, FIELD_OS_PATH}},
{VOLUME, {TTYP_DISK_VOLUME, FIELD_OS_VOLUME}},
{ALBUM, {TTYP_ALBUM, FIELD_STRING}},
{TRACK, {TTYP_TRACK_NUMBER, FIELD_INTEGER}},
{BITRATE, {TTYP_BITRATE, FIELD_INTEGER}},
{COMMENT, {TTYP_COMMENT, FIELD_STRING}},
{GENRE, {TTYP_GENRE, FIELD_STRING}},
{IMPORT_DATE, {TTYP_IMPORT_DATE, FIELD_DATE}},
{KEY_LYRICS, {TTYP_KEY_LYRICS, FIELD_STRING}},
{LAST_PLAYED, {TTYP_LAST_PLAYED, FIELD_DATE}},
{PLAYCOUNT, {TTYP_PLAYCOUNT, FIELD_INTEGER}},
{PLAYTIME, {TTYP_PLAYTIME, FIELD_INTEGER}},
{RANKING, {TTYP_RANKING, FIELD_INTEGER}},
{RELEASE_DATE, {TTYP_RELEASE_DATE, FIELD_DATE}},
{BPM, {TTYP_BPM, FIELD_DOUBLE}},
{BPM_QUALITY, {TTYP_BPM_QUALITY, FIELD_INTEGER}},
{PEAK_DB, {TTYP_PEAK_DB, FIELD_DOUBLE}},
{PERCEIVED_DB, {TTYP_PERCEIVED_DB, FIELD_DOUBLE}}, // may be negative
// list
{LABEL, {TTYP_LABEL, FIELD_STRING_LIST}}, // is LIST (not limited string set, despite appearances)
{POS, {TTYP_POS, FIELD_DOUBLE}},
{TYPE, {TTYP_TYPE, FIELD_INTEGER}} // actually limited integer set
};
}
// DTOR
[Mixxx-devel] Behringer UCA222 sampling DC offset?
I bought a Behringer UCA222 (USB 48 KHz) card after reading a bunch of rave reviews but found there's a significant DC offset that I can't easily re-center post input-sampling. That glitch doesn't happen with an older/cheaper Edirol UA-1A. Can anybody share their experience when using the UCA222 card for input (not output)? thx, -- p -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/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
[Mixxx-devel] in-bound SysEx arg?
I can now send generic/binary buffers to Mixxx via SysEx with pre-encoding to 7-bit and js decoding back to 8-bit but it seems the 'data' argument is not really an array but an object (or array object?) so I can't directly use one of the myriad array functions to pop the sysex header and eos tail (array.shift(), array.slice(), array.splice(), etc.), but 1st have to copy it to a temporary buffer. Didn't find any built-in conversion online, only manual copy loops, did I miss something? Since sysex typically carries pretty large messages, it'd be nice if it were a native array. The MIDI scripting doc also mentions a built-in Alsa encoding from Nov 2012 onward that sends each byte as two separate nybbles so it doubles the message size -- has anybody ever seen that behavior? Is there a reliable way for a recipient to detect that encoding? thx cheers, -- 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=48808831iu=/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
Re: [Mixxx-devel] Engine time-stamp position scratching?
On Sun, 14 Jul 2013 11:40:59 +0200
Sean M. Pappalardo - D.J. Pegasus
spappalardo-opwvymzfgylytjvyw6y...@public.gmane.org wrote:
On 07/14/2013 01:53 AM, petah wrote:
From your experience do you think SysEx can be used to pass around any type
of binary data?
No. The high bit cannot be set in any of the data bytes since doing so
signals a status byte and will abort the SysEx.
Right, that's why I wrote an 8-7-8 bit codec.
For arbitrary data, I'd use HID which Mixxx fully supports now.
Well common-hid-packet-parser.js is rather large and complex and I'm
interfacing a soft-device so simulating a virtual HID device may not be
trivial without root access. Theoretically SysEx should do the job because I
can choose whatever data format on both ends and my 7-to-8 bit decoder is quite
small:
function Decode7(encoded7_data)
{
var dec8data = [];
var mask = 0;
for (var i = 0, j = 0; i encoded7_data.length; i++, j++)
{ if (0 == (i 7))
{ // get new mask
mask = encoded7_data[i++];
}
// recompute cycle index
var ind = (i 7);
// retrieve high-bit
var highbit = (mask (0x80 ind)) ind;
// combine low-7 with high-bit
dec8data[j] = encoded7_data[i] | highbit;
}
return dec8data;
}
It looks like I just need to make sure I don't use an existing SysEx
manufacturer ID or are there more caveats?
thx cheers,
-- 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=48808831iu=/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
Re: [Mixxx-devel] Engine time-stamp position scratching?
On Fri, 12 Jul 2013 08:30:14 +0200
Sean M. Pappalardo - D.J. Pegasus
spappalardo-opwvymzfgylytjvyw6y...@public.gmane.org wrote:
On 07/10/2013 09:51 PM, RJ Ryan wrote:
Yes! If you want to use the position scratch controller in the engine
then that's one way you could tell Mixxx to move smoothly to a position.
I was assuming you wanted to work more like vinyl control though in that
it would control Mixxx's normal playback rate.
To do that,
set [ChannelX],scratch_position_enable 1
set [ChannelX],scratch_position to the desired position delta from the
current position
This is how the mouse tells mixxx to scratch back and forth from the
position at which enable was changed to 1.
This sounds a bit closer to what I'm looking for to fully support
moving-platter controllers (please add it to the wiki,) but what about
when time stamps are provided, as which moving-platter controllers do.
(I was under the impression that the engine still doesn't have a way to
handle those.)
I'd really appreciate it if the wiki could be updated with this message type
incl. resolution/limitations. I understand that how often it can actually be
called is another issue but that'd be a good start.
Sean - is your Serato driver the only one with SysEx-based messages? From your
experience do you think SysEx can be used to pass around any type of binary
data?
I attached an 8/7-bit transcoder (8-7 in C++, 7-8 in javascript), but haven't
tested it on Mixxx yet.
thx cheers,
-- p
// Midi SysEx encoder (C++) and decoder (javascript)
// Encode 8-to-7-bit (C++) -
SysExEncoder::SysExEncoder(const std::vectoruint8_t src_bin_data)
{
const size_t src_bin_sz = src_bin_data.size();
wxASSERT(src_bin_sz 0);
const size_t calc_enc_sz = ((src_bin_sz * 8 * 8 / 7) + 7) 3;
m_Encoded7Data.resize(calc_enc_sz, 0);
for (int i = 0, j = 0; i src_bin_sz; i++, j++)
{
const int ind = (i % 7);
if (ind == 0)
{ // reserve mask
m_Encoded7Data[j++] = 0;
}
const uint8_t c = src_bin_data[i];
const size_t mask_ind = j - (ind + 1);
// store high-bit
m_Encoded7Data[mask_ind] |= (c 0x80) (ind + 1);
// store lower 7 bits
m_Encoded7Data[j] = c 0x7F;
}
}
// Decode7 (javascript)
function Decode7(encoded7_data)
{
var dec8data = [];
var mask = 0;
for (var i = 0, j = 0; i encoded7_data.length; i++, j++)
{ if (0 == (i 7))
{ // get new mask
mask = encoded7_data[i++];
}
// recompute cycle index
var ind = (i 7);
// retrieve high-bit
var highbit = (mask (0x80 ind)) ind;
// combine low-7 with high-bit
dec8data[j] = encoded7_data[i] | highbit;
}
return dec8data;
}
--
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=48808831iu=/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
Re: [Mixxx-devel] high-res MIDI interface with pull architecture?
On Thu, 11 Jul 2013 11:07:05 +0200 Daniel Schürmann daschuer-opwvymzfgylytjvyw6y...@public.gmane.org wrote: Hi Petah, /mixxx/src/engine/positionscratchcontroller.cpp :-) I like the compact source size and some variable names like m_dPositionDeltaSum :) Not thrilled about m_bEnableInertia and kExponentialDecay. I now understand the limitation of position changes because Mixxx's sound engine has to ramp up on a disruption but an elastic needle would be just as nasty. I'll take your word those a just for the mouse. Also I'm usure about Mixxx's strict definition of the word scratch. In Traktor it was a sound effect for nondescript/random controller movements, i.e. the opposite of what a scratch master expects. Anyway, back to my code which I somehow broke during refactoring... 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=48808831iu=/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
[Mixxx-devel] high-res MIDI interface with pull architecture?
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=48808831iu=/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
Re: [Mixxx-devel] high-res MIDI interface with pull architecture?
Is there a reason to make a request/response setup rather than a broadcast setup? Isn't your processing code constantly reading this data as the CD spins? Yes, approx every 4 milliseconds. If I were to write a 64-byte SysEx MIDI message that often it'd likely overwhelm the system. Since Mixxx doesn't need data that often and can only process it without glitches up to a certain point, as Owen pointed out, the pull model makes more sense. is it possible to give Mixxx a Javascript callback with a maximum timer? it doesn't need to be a constant period, i.e. it could be called whenever possible. 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 mi...@djpetah.com 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=48808831iu=/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 -- 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=48808831iu=/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
Re: [Mixxx-devel] high-res MIDI interface with pull architecture?
On Wed, 10 Jul 2013 14:47:42 -0400 RJ Ryan rryan-opwvymzfgylytjvyw6y...@public.gmane.org wrote: On Wed, Jul 10, 2013 at 2:05 PM, petah mixxx-356rgwljecpbdgjk7y7...@public.gmane.org wrote: Is there a reason to make a request/response setup rather than a broadcast setup? Isn't your processing code constantly reading this data as the CD spins? Yes, approx every 4 milliseconds. If I were to write a 64-byte SysEx MIDI message that often it'd likely overwhelm the system. That's 16000 bytes/sec. Which is really not that much data. MIDI (i.e the wire protocol) has a max of 31.25kbits/s but MIDI over USB usually ignores that limitation. it's actually soft-midi (running on localhost) so I'm guessing would be even faster. So the Javascript driver would keep up when called that often? If you find it's an issue, you could just rate limit it on your side. Is there a way to find out when a problem occurs? Otherwise my side of the code is blind (or deaf) and won't know when to rate-limit. Since Mixxx doesn't need data that often and can only process it without glitches up to a certain point, as Owen pointed out, the pull model makes more sense. 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. The controller processing thread runs at lower priority than the audio processing callback so it really should not matter if the scheduler is working correctly. It does matter on a few messages like Cue Play (dropmix), Owen's source code for the xwax driver also has a comment about it. Adding the wire overhead and latency of a request every time you want data seems silly because the time to the next request is a function of time alone and the request carries no information. Well I'm still unclear on what Mixxx's limit is wrt updating the play position. Owen mentioned that if updated too often it'd completely garble the sound which isn't a function of MIDI speed but some internal Mixxx factors. That's the variable I'd like to extract to make sure I never go beyond that limit. If that limit is consistently beyond my update frequency then you're right and requesting an update from my driver makes no sense. I'd just need a reliable way to establish that's the case in the realtime since it may depend on Mixxx's current workload. 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-356rgwljecpbdgjk7y7...@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=48808831iu=/4140/ostg.clktrk ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list mixxx-devel-5nwgofrqmnerv+lv9mx5uipxlwaov...@public.gmane.org https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- 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=48808831iu=/4140/ostg.clktrk ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list mixxx-devel-5nwgofrqmnerv+lv9mx5uipxlwaov...@public.gmane.org https://lists.sourceforge.net/lists/listinfo/mixxx-devel
Re: [Mixxx-devel] high-res MIDI interface with pull architecture?
On Wed, 10 Jul 2013 18:10:46 -0400 Owen Williams owilliams-opwvymzfgylytjvyw6y...@public.gmane.org wrote: I had no idea this existed! Sorry to steer you wrong. Does it /really/ exist though? Maybe it just lives in RJ's delirious mind, LOL. No harm done... after NI's secretive SM forums anything else is a pleasure. cheers, -- p On Wed, 2013-07-10 at 22:27 +0200, petah wrote: On Wed, 10 Jul 2013 15:51:46 -0400 RJ Ryan rryan-opwvymzfgylytjvyw6y...@public.gmane.org wrote: Yes! If you want to use the position scratch controller in the engine then that's one way you could tell Mixxx to move smoothly to a position. I was assuming you wanted to work more like vinyl control though in that it would control Mixxx's normal playback rate. To do that, set [ChannelX],scratch_position_enable 1 set [ChannelX],scratch_position to the desired position delta from the current position That's really interesting. I found scratch_position in the src code but not in the wiki, which may explain some of my stupid questions (or it actually is in the wiki and I'm even more retarded). I couldn't figure out the format/resolution of that message from the code, would it be possible to add it to the wiki? Obviously I don't plan to randomly drop the needle around, just want to make sure FF/REW/reloop are within the delta range. thx a lot! -- 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=48808831iu=/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
Re: [Mixxx-devel] absolute position ?
Hi Owen, Like I said, we do playback based on pitch, not position. I assume you mean pitch adjustments, not an 11-bit MIDI pitch message. Is there a problem you're trying to solve? Yes; the specific problem I'm trying to solve is interfacing my homegrown CDJ timecode program with Mixxx, xwax-style. If I could pass a high resolution time position to Mixxx's internals then tempo, pitch bend, FF/REW, cue recall, etc, are all implicitly handled with one single message and the driver will be simple. I'd just need to loopback from my app to Javascript using a MIDI SysEx or HID message (or a MIDI bundle). However, if I cannot send an absolute time position, I'll need a slew of different messages for tempo, pitch bend, FF/REW, etc., synthesized on my end, which is likely to be much less precise, then pass those individual messages to Javascript. This would be much more complex, less reliable and because the CDJ track position will drift from Mixxx's track position could even hit a CD track boundaries at which point it's stuck. Btw I did look at xwax but due to its focus it's lacking some features that Mixxx has, so I'm between a rock and a hard place. Is there something wrong with how absolute position playback is working? AFAIK there currently is no absolute position playback. The closest is the playPosition message but the position is normalized over the track's length, i.e. I'd have to retrieve the track length from Mixxx and unscale my absolute position but that doesn't tell me how much resolution comes through, i.e. if a pitch bend on the CDJ would even be registered by Mixxx. If you can help me with the above, say by adding such an absolute playMsPosition message or showing me how to hook an alternative communication path to Mixxx (Unix pipe, shared lib/DLL, OSC, etc.) then please contact me offline so we talk code instead of semantics :) I'm guessing a shared lib binary plug-in model would be most efficient since it'd bypass Javascript at runtime (could still have a JS load-time hook). I'd be willing to implement an OSC server in this first shared lib so it's for the benefit of all. thx cheers, -- p On Sat, 2013-07-06 at 19:08 +0200, petah wrote: On Sat, 06 Jul 2013 11:14:13 -0400 Owen Williams owilliams-opwvymzfgylytjvyw6y...@public.gmane.org wrote: I'm confused, what are you trying to do? For vinylcontrol absolute mode, we mostly use the pitch value and then nudge the speed up or down if it drifts too far from the reported timecode position.For CDs, if it's more than .1 seconds off then we just seek to that position. I don't really see the point of having 22 bit resolution. 22-bits is the maximum resolution the CDJ timecode returns for a single-track CD. On a 4-track CD a timestamp is 2.38ms or a worst-case latency of ~5ms. OTOH nudging +/- 0.1 second is 100ms or 20x worse. Dropping seek commands based on acceptable drift is fine on full-resolution incoming timecode at the receiver end, but doing roundtrips and diffs to reach an absolute position makes no sense if the timecode is absolute to begin with. I'd turn the comment around: I don't see the point of truncating bits in the protocol to later try recovering them by chasing the needle :) -- p On Sat, 2013-07-06 at 11:56 +0200, petah wrote: What message should be used to set the absolute position of the virtual needle of a loaded track given an absolute time position, f.ex. 2mins 34secs 567millisecs? I went through all the relevant docs (I think), incl. controls and HID mappings and didn't find a clear solution. I need to match an analog CDJ's time display with Mixxx's via a timecode CD using absolute timestamps (4 tracks x 15min), i.e. time scale between CDJ/Mixxx needs to be 1:1 and clamp, not stretch. F.ex. vinylcontrol_mode is a 3-way switch, one being absolute, but I don't see the set absolute time message. playPosition is scaled over the length of the track loaded in mixxx, which won't match a timecode CD's track. scratch2 affects the absolute speed, hence the relative position. The absolute time position needs to have at least 22-bit resolution so a gentle pitch bend can go through the engine via that cursor position and behave as expected, i.e. if any scaling/compression is applied along the way it wouldn't chop off the lower bits. It's just to control track position. Precision is critical but right now latency isn't. thx, -- p -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list mixxx-devel-5nwgofrqmnerv+lv9mx5uipxlwaov...@public.gmane.org https
Re: [Mixxx-devel] Javascript UDP server for OpenSoundControl or else
Hi Daniel, sorry didn't see your post until now. On Sat, 6 Jul 2013 21:10:24 +0200 Daniel Schürmann daschuer-opwvymzfgylytjvyw6y...@public.gmane.org wrote: Hi petah, I am thinking for a while for a similar solution for Mixxx. IMHO this could be relay great addition to have an addition IPC automation interface for Mixxx. It would be nice if you could describe some more details of your project. My project is pretty single-minded, I put the source code and as much info as bearable on www.hackerdjs.com/software/cdj2midi.html (no more URL posting lest I get branded a poser:) Here some unsorted points: * OSC: would be a nice addition for Mixxx, but IMHO there is no strong demand because of a special use case. We may update our Wiki http://www.mixxx.org/wiki/doku.php/osc_backend if we have any. I think OSC's #1 advantage is it's backwards-compatible with MIDI but has much more data resolution. All the discovery/learn stuff is overkill because so few other software implement it. I wrote an OSC client using OSCpack a while back and it's simple enough. * Qmidinet http://qmidinet.sourceforge.net/qmidinet-index.html, is a nice Midi UDP solution which works fine with Mixxx. It would be nice if we implement it's Interface within Mixxx itself. That sounds great, I'll check it out. OSC is also UDP-based btw. * MPRIS-Dbus interface: This should be not a big deal to implemet because of the very well Qt Dbus interface. But a lot of work anyway. https://blueprints.launchpad.net/mixxx/+spec/dbus http://www.mail-archive.com/mixxx-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org/msg04684.html I've never written to a DBus so can't comment one way or another. * alsa snd_seq: Let your application be a midi device. Then you can use the full power of midi scripting inside Mixxx. http://fundamental-code.com/midi/ Vanilla MIDI doesn't really solve my problem with is resolution. Hope that heps! Definitely does, will check out the links, thx! -- p Kind regards, Daniel 2013/7/6 petah mixxx-356rgwljecpbdgjk7y7...@public.gmane.org I'm looking for a quick loopback path between my stdalone app and Mixxx; I'm guessing a Javascript server to receive OSC messages is too tall an order. Any other suggestions to implement a /very basic/ loopback test (with just start/stop, say) that doesn't require diving into Mixxx's bowels? For now I don't mind if it's Linux-specific, incl. a hardcoded pipe hack. thx cheers, -- p -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list mixxx-devel-5nwgofrqmnerv+lv9mx5uipxlwaov...@public.gmane.org https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ 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
Re: [Mixxx-devel] Javascript UDP server for OpenSoundControl or else
Hi again, http://www.hackerdjs.com/software/cdj2midi.html I have not read all details, but It looks like a an other kind of vinyl control. It's CDJ-only but yes it's in the same category. Main difference is my timecode isn't based on a commercial system (may come in handy if Mixxx gets too popular and those companies want to bring in lawyers), has better latency and needs only 1 audio channel per CDJ. I think we have some vinyl control experts on this list to help you to integrate your approach right into Mixxx. Yes; Owen already gave me a good whipping :) One of the challenges is my algorithm is completely alien and as Owen mentioned, there's a limit to how often Mixxx's position cursor can be changed so a higher-latency/high-res driver may hit a brick wall. I'd be great to know which variables establish this limit (CPU speed, HW card latency, internal features depending on FFT width, etc.). Vanilla MIDI doesn't really solve my problem with is resolution. I have access to a RMX2 controller which also uses 14 bit resolution scratching. And it is likely that this will part of our control system refactoring. So if that might be a possible way for you, I would be happy to work with you on a generic solution. https://bugs.launchpad.net/mixxx/+bug/1159453 I'd love to but there are wider considerations like not breaking compatibility with all the existing drivers. Maybe the least-intrusive method would be for Mixxx to define a high-level MIDI message template with more resolution based on MIDI SysEx. A better solution I think is for Mixxx to expose a binary shared-lib/DLL API via a class factory for drivers that need to bypass Javascript at runtime but still expose JS prefs at load-time. I don't know enough about Mixxx's internals to say if either makes sense though... other elders should chime in :) Btw another advantage of OSC is that since it's UDP-based it'd be trivial to implement loopbacks, probably make remote debugging easier and could interface with NI/Ableton software. Most end-users probably don't care about those. I've done a bunch of UDP coding recently for a remote log receiver but it's a far cry from the latency range audio apps need. cheers, -- p -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ 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
[Mixxx-devel] absolute position ?
What message should be used to set the absolute position of the virtual needle of a loaded track given an absolute time position, f.ex. 2mins 34secs 567millisecs? I went through all the relevant docs (I think), incl. controls and HID mappings and didn't find a clear solution. I need to match an analog CDJ's time display with Mixxx's via a timecode CD using absolute timestamps (4 tracks x 15min), i.e. time scale between CDJ/Mixxx needs to be 1:1 and clamp, not stretch. F.ex. vinylcontrol_mode is a 3-way switch, one being absolute, but I don't see the set absolute time message. playPosition is scaled over the length of the track loaded in mixxx, which won't match a timecode CD's track. scratch2 affects the absolute speed, hence the relative position. The absolute time position needs to have at least 22-bit resolution so a gentle pitch bend can go through the engine via that cursor position and behave as expected, i.e. if any scaling/compression is applied along the way it wouldn't chop off the lower bits. It's just to control track position. Precision is critical but right now latency isn't. thx, -- p -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ 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
Re: [Mixxx-devel] absolute position ?
On Sat, 06 Jul 2013 11:14:13 -0400 Owen Williams owilliams-opwvymzfgylytjvyw6y...@public.gmane.org wrote: I'm confused, what are you trying to do? For vinylcontrol absolute mode, we mostly use the pitch value and then nudge the speed up or down if it drifts too far from the reported timecode position.For CDs, if it's more than .1 seconds off then we just seek to that position. I don't really see the point of having 22 bit resolution. 22-bits is the maximum resolution the CDJ timecode returns for a single-track CD. On a 4-track CD a timestamp is 2.38ms or a worst-case latency of ~5ms. OTOH nudging +/- 0.1 second is 100ms or 20x worse. Dropping seek commands based on acceptable drift is fine on full-resolution incoming timecode at the receiver end, but doing roundtrips and diffs to reach an absolute position makes no sense if the timecode is absolute to begin with. I'd turn the comment around: I don't see the point of truncating bits in the protocol to later try recovering them by chasing the needle :) -- p On Sat, 2013-07-06 at 11:56 +0200, petah wrote: What message should be used to set the absolute position of the virtual needle of a loaded track given an absolute time position, f.ex. 2mins 34secs 567millisecs? I went through all the relevant docs (I think), incl. controls and HID mappings and didn't find a clear solution. I need to match an analog CDJ's time display with Mixxx's via a timecode CD using absolute timestamps (4 tracks x 15min), i.e. time scale between CDJ/Mixxx needs to be 1:1 and clamp, not stretch. F.ex. vinylcontrol_mode is a 3-way switch, one being absolute, but I don't see the set absolute time message. playPosition is scaled over the length of the track loaded in mixxx, which won't match a timecode CD's track. scratch2 affects the absolute speed, hence the relative position. The absolute time position needs to have at least 22-bit resolution so a gentle pitch bend can go through the engine via that cursor position and behave as expected, i.e. if any scaling/compression is applied along the way it wouldn't chop off the lower bits. It's just to control track position. Precision is critical but right now latency isn't. thx, -- p -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list mixxx-devel-5nwgofrqmnerv+lv9mx5uipxlwaov...@public.gmane.org https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list mixxx-devel-5nwgofrqmnerv+lv9mx5uipxlwaov...@public.gmane.org https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ 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
Re: [Mixxx-devel] absolute position ?
On Sat, 06 Jul 2013 11:14:13 -0400 Owen Williams owilliams-opwvymzfgylytjvyw6y...@public.gmane.org wrote: I'm confused, what are you trying to do? For vinylcontrol absolute mode, we mostly use the pitch value and then nudge the speed up or down if it drifts too far from the reported timecode position.For CDs, if it's more than .1 seconds off then we just seek to that position. I don't really see the point of having 22 bit resolution. 22-bits is the maximum resolution the CDJ timecode returns for a single-track CD. On a 4-track CD a timestamp is 2.38ms or a worst-case latency of ~5ms. OTOH nudging +/- 0.1 second is 100ms or 20x worse. Dropping seek commands based on acceptable drift is fine on full-resolution incoming timecode at the receiver end, but doing roundtrips and diffs to reach an absolute position makes no sense if the timecode is absolute to begin with. I'd turn the comment around: I don't see the point of truncating bits in the protocol to later try recovering them by chasing the needle :) -- p On Sat, 2013-07-06 at 11:56 +0200, petah wrote: What message should be used to set the absolute position of the virtual needle of a loaded track given an absolute time position, f.ex. 2mins 34secs 567millisecs? I went through all the relevant docs (I think), incl. controls and HID mappings and didn't find a clear solution. I need to match an analog CDJ's time display with Mixxx's via a timecode CD using absolute timestamps (4 tracks x 15min), i.e. time scale between CDJ/Mixxx needs to be 1:1 and clamp, not stretch. F.ex. vinylcontrol_mode is a 3-way switch, one being absolute, but I don't see the set absolute time message. playPosition is scaled over the length of the track loaded in mixxx, which won't match a timecode CD's track. scratch2 affects the absolute speed, hence the relative position. The absolute time position needs to have at least 22-bit resolution so a gentle pitch bend can go through the engine via that cursor position and behave as expected, i.e. if any scaling/compression is applied along the way it wouldn't chop off the lower bits. It's just to control track position. Precision is critical but right now latency isn't. thx, -- p -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list mixxx-devel-5nwgofrqmnerv+lv9mx5uipxlwaov...@public.gmane.org https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list mixxx-devel-5nwgofrqmnerv+lv9mx5uipxlwaov...@public.gmane.org https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ 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
[Mixxx-devel] Javascript UDP server for OpenSoundControl or else
I'm looking for a quick loopback path between my stdalone app and Mixxx; I'm guessing a Javascript server to receive OSC messages is too tall an order. Any other suggestions to implement a /very basic/ loopback test (with just start/stop, say) that doesn't require diving into Mixxx's bowels? For now I don't mind if it's Linux-specific, incl. a hardcoded pipe hack. thx cheers, -- p -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ 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
[Mixxx-devel] Debian build instructions update
I'm pretty sure the section in compiling_on_linux/Troubleshooting/Debian is wrong (it's based on instructions from 2010): - Debian current is now Wheezy - assuming all the commands are root, an apt-get source portaudio19 will create a dir in /root/portaudio(...), not /portaudio(...) which is what the doc says - it says to cd into /portaudioXXX/debian, then 'nano debian/rules', which is one dir too deep - there's no JACK reference in the rules file, which stops way before line 48 It builds runs on Debian if you just 'apt-get libportaudio2', at least on i386, so you can probably scrap that whole section. This is on a freshly installed system from 'debian-7.1.0-i386-netinst.iso' (hardware not so fresh though). I currently build a custom/static PortAudio on my less-comatose x64 systems so didn't test on them yet, would be nice if someone could confirm. cheers, -- p -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ 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
[Mixxx-devel] CDJ2MIDI update Mixxx integration?
Hi RJ, I finally ported my CDJ2MIDI soft-interface to Linux using PortAudio/Alsa; turns out the earlier zip was missing a bunch of source files... I had also forgotten that the timecode debugger was fairly large. I tested it with my same ol' crappy UA-1A interface and it seems to work fine,, There'll be some bugs to fix if the audio-in interface doesn't handle native 44.1 khz but it'll do for now. I uploaded the new source at http://www.hackerdjs.com/software/cdj2midi.html and added some technical info about the timecode format and screenshots. It's still wxWidgets-based cause I'm a total Qt noob, juggling a bunch of other projects at the same time and have to try integrating it with Mixxx by August. What would be the easiest way for me to integrate Mixxx with my separate app, i.e. without trying to merge both source codes/binaries? I'd use MIDI except it wouldn't allow me to send the full-resolution absolute timestamps (I don't have relative positions). Do you recommend I try to generate HID messages from my app or is there a simpler way like using a pipe? Timestamps cue-recall are time-critical, the rest isn't right now. Right now I just care about a quick dirty solution for this Summer; afterwards I'll have time to do it the right way. thx a lot cheers, -- p -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ 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
Re: [Mixxx-devel] CDJ2MIDI update Mixxx integration?
On Tue, 2 Jul 2013 16:03:19 -0400 RJ Ryan rryan-opwvymzfgylytjvyw6y...@public.gmane.org wrote: For compatibility and portability I'd suggest sticking with either MIDI or HID. That way you can interoperate with any existing Mixxx 1.11.0 installs and it will require no/minimal code changes to Mixxx. Adding a custom pipe also present UI challenges around enumeration and selection of which pipe to use. We already have a good system in place for MIDI / HID device enumeration / UI selection. Ok HID seems like the best solution from what I gleaned from the docs. Back when I used Traktor on Windows I remember I had to use a MIDI loopback device for my app to communicate with it, I assume that's not necessary with HID and there's a way for 2 apps to communicate directly. Can you recommend an existing Mixxx driver I should use as basis? I need the absolute timestamps to go through a really low-latency pipe. Also I'm hoping that having a low-latency PortAudio/Alsa capture loop to read timecode from the CDJs won't interfere with Mixxx's use of PA for output to the audio card. I'll have the UA-1A as input and an M-Audio FastTrack Pro for music output. Btw I apologize for my lack of low-level Mixxx know-how; I've wasted about a month determining the new DJing laptop I bought (XPS13) had a defective fan, was overoptimistic on porting my win32 code to Linux... and really have no excuse :) thx cheers, -- p -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ 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
Re: [Mixxx-devel] OSC = RIP ?
On 06/09/2013 02:04 PM, petah wrote: I'm dusting off my CDJ2MIDI code which at the time sent out either MIDI or OSC messages because NI Ableton had press releases galore about supporting it. I know OSC is still used for touch interfaces but is it still relevant for audio? if not I'd rather cull it. As in Pioneer CDJ? Mixxx 1.11.0 now speaks HID natively and we have presets for a few Pioneer CDJ units already, so if that's what your code worked with, you can safely abandon it. No, my code is for the original, analog-only CDJs with only stereo RCA out on the back, no USB or MIDI, I've got a video at http://www.hackerdjs.com/software. The rationale is that you can be sure to at least find one of these old CDJ-100 buggers at some gig, and without something like CDJ2MIDI to interface with Mixxx you'd have to schlep some MIDI interface with you as backup. It used to be Windows-only code which I'm now porting to Linux, it'd still need testing on different analog CDs to ensure they behave the same. Btw another reason I implemented OSC was because messages have a much larger resolution than MIDI. cheers, -- p We would love if you could add presets for any CDJs you may have though! Sincerely, Sean M. Pappalardo D.J. Pegasus Mixxx Developer - Controller Specialist -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ 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
Re: [Mixxx-devel] OSC = RIP ?
On Mon, 10 Jun 2013 13:20:17 -0400 RJ Ryan russelljryan-re5jqeeqqe8avxtiumw...@public.gmane.org wrote: Yep, that's how you would implement it. Our MIDI controller support and HID controller support are part of a framework for defining control systems. Adding OSC would fit right in as a new controller subsystem. OSC is a superset of MIDI, so implementing that part should be easy. I'll send my implementation source when I get my hand on it. IIRC the whole hierarchical command discovery, which would be the tough part to implement, was never implemented by NI/Ableton but the MIDI subset definitely was. Btw I saw Ross Bencina (of PortAudio fame) released a new OSCPack a few weeks ago so apologies to Ross if he comes across my message title :) -- p -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ 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
Re: [Mixxx-devel] OSC = RIP ?
On Tue, 11 Jun 2013 09:41:17 +0200 Sean M. Pappalardo - D.J. Pegasus spappalardo-opwvymzfgylytjvyw6y...@public.gmane.org wrote: On 06/11/2013 09:26 AM, petah wrote: No, my code is for the original, analog-only CDJs with only stereo RCA out on the back, no USB or MIDI, I've got a video at http://www.hackerdjs.com/software. Wow, that's really cool! You should mention this on the xwax mailing list as well since I know Radiomark would be interested in that since he was kicking around designing his own time code too. If Radiomark == Mark Hills then it was he who introduced me to RJ. He's welcome to grab the part of my code that makes sense for xwax but I still think it deserves a native Mixxx implementation because it also post-processes timestamps to detect key presses. Or maybe I can slice the code in half, with the low-level timestamp reading in xwax and the key interpreter in Mixxx, assuming overhead isn't excessive. cheers, -- p -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ 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
[Mixxx-devel] OSC = RIP ?
I'm dusting off my CDJ2MIDI code which at the time sent out either MIDI or OSC messages because NI Ableton had press releases galore about supporting it. I know OSC is still used for touch interfaces but is it still relevant for audio? if not I'd rather cull it. thx, -- p -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ 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
Re: [Mixxx-devel] Directory-hash calculation during library-rescan
On Wed, 5 Jun 2013 22:46:57 -0700 (PDT) Steven Boswell II ulatekh-/e1597as9lqavxtiumw...@public.gmane.org wrote: Right now I'm rescanning my track collection on my laptop, and I expected it to be a short operation, but it's taking forever. I'm guessing it's because I moved a large part of my track collection to a different partition on my hard drive, even though the path remained the same. The issue is that QDirIterator doesn't present the tracks in any particular order; it'll be dictated by how they happened to be stored in the underlying filesystem. When I moved the track collection, that permuted the files in each directory. The issue is that the directory-hash calculation isn't order-independent; it calculates the directory hash by appending all the filenames to one string. If we changed it to calculate the hash of each filename individually, and XORed those together, then it would be order-independent, and shouldn't detect less changes than the previous method. Thoughts? I'm guessing it should be seen as a generic, recursive hash(files[n]) - hash(parent_dir) problem, in which case using XOR wouldn't report a file's movement to a grandparent because ((a ^ b) ^ c)) == (a ^ (b ^ c)) and surely the point is to do a top-down traversal and actually detect such movements? My first instinct would be to wrap QDirIterator with a qsort() so it's deterministic and doesn't fluctuate across different OSes/Filesystems, then it's an optimization problem but not trivial. I read a paper a while back that used MD6 hashes because they're immune to order and can be massively parallelized on GPUs, and used a header/footer block hash for faster discrimination. It was for file deduplication though, in Mixxx's case I don't see how you can avoid having to recompute the hash of a file that suddenly popped up; you can never be certain it was the same file that disappeared from another location until a full rehash... unless the move operation is done from within the Mixxx UI or the hash is embedded in the file's metadata. -- p -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ 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
Re: [Mixxx-devel] Directory-hash calculation during library-rescan
On Sun, 9 Jun 2013 09:03:12 -0400 RJ Ryan russelljryan-re5jqeeqqe8avxtiumw...@public.gmane.org wrote: We don't hash the file contents during library scanning. For context, the hash Steven is referring to is a per-directory hash that is used to determine whether the directory should be rescanned. The way it works today is that it concatenates all the names of files/dirs in the directory and hashes that. If the hash is different from what we saw before we rescan the directory. Steven is right that we should switch to something order independent. I've also wanted to include mtimes in there for a while but not sure if that would result in an extra stat or not on all the common filesystems we care about. Hmm, just using the filename would worry me, I have a lot of tracks with the same name and even metadata, usually got the crappy version first (p2p, friend, nasty vinyl rip) then the high-quality, legit version. Timestamps quickly go haywire even if you don't travel across timezones with an NTP-synced laptop. I wouldn't trust a file system's meta-data anyway since the medium could be passed from someone else at the last minute. I don't think git uses either. Before a gig I really need to be absolutely sure the file I'm queuing doesn't have a huge glitch half-way through or is the low-gain version that'll come out crap. Presumably embedding metadata isn't on the table due to WAV/AIFF support? Wrt to moving files, IIRC Traktor solved it by requiring you to do it from within their UI or it'd pop a where is it now dialog, was a pain in the ass though. -- p -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ 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
Re: [Mixxx-devel] Hate JavaScript and XML? ...then keep reading!
Hey RJ, welcome back:)
On Wed, 29 May 2013 15:40:04 -0400
RJ Ryan russelljryan-re5jqeeqqe8avxtiumw...@public.gmane.org wrote:
So if this declarative table (which is obviously needed to standardize the
glue interface) was returned from script itself that'd be ok right? After
all Mixxx doesn't need it to be a disk file as long as it can retrieve a
standard data structure. In that case driver writers could choose whatever
storage they want if they're allergic to one file format or another.
Switching to such an architecture just needs a standard Javascript
function that loads existing XMLs.
This would work fine if all Mixxx needed to do was load a preset but it
also has to be able to serialize presets. If the script returns the
mappings from a standard function call then Mixxx would have no way to
write an updated script with the user's modified mappings.
I don't have an up-to-date/comprehensive picture of the controller landscape,
in originality or popularity; I was thinking of a standardized declarative
layer as an entry point into Mixxx.
F.ex. I attached a (curated) snippet I wrote to decode a Logitech Rumblepad;
piping the raw, procedural input through a little state machine so the output
is declarative. Don't know how applicable that is in general, especially for
controllers that aren't read-only and give significant feedback to the user,
but it's easier to build logic on top of declarative input vs squaring
complexity by blending one state machine with another.
Are there other critical latency cases like resuming a cue to do a Roger
Sanchez style needle-drop mix? (good luck:)
Well, there are lot of issues around wheels in general in Mixxx and our
solution today kind of sucks. There's no standard way for a preset to
provide options the user can tweak such as wheel sensitivities -- our
answer is just pop open the JS file in a text editor and change this
number. Also, for wheels that act normal for whatever values of normal
we define, we should provide a generalized non-script infrastructure for
processing scratching and jog-wheeling that bypasses script and supports
the user customizing it in the most common ways (sensitivity,
touch-enabling, inertia, etc.)
Assuming Mixxx has a fixed tick() for controller input, a wheel is just an ID
with a signed delta right? Sensitivity inertia would be a level above. Maybe
it's possible to create a UI library for the most common widgets, if the wiki
had a list of various controller widgets in categories or at least tags it'd
help get some perspective.
No doubt you'll have to make tough decisions about where to split
functionality. You can neither have a script-only nor a UI-only interface
that'd cover all uses, both extremes would freak out new users. IMHO the danger
is getting sucked into the quest for a silver bullet (like the iPod's
click-wheel), instead I'd try to take the same path as Flash which started
mostly UI and then nudged those who could/wanted to script. Some users will
inevitably complain and be much louder than happy ones... NI forums were not
exactly a yoga room.
I'll reply to your other points tomorrow (dead tired now) but looking up my a55
I'd say the more complex MIDI controllers make sense for DJ/producers on
software like Ableton Live with tons of raw samples/channels but little for
crude 2-track DJing. If Jean-Michel Jarre type laser harp / JazzMutant
wiz-bang visual interfaces aren't so yesterday yet, I bet they soon will
(Qbert vs iPod operator?)
My opinion's probably not relevant because I quickly had to drop most of
Traktor's gimmicks and use the main mixer when I was haplessly pushed into the
arena with real DJs who wanted to beatmatch for fun (I now have a 3/4
flamenco-house track up my sleeve:) or just had to transition with a resident
whose library was 20 bpm above mine. Also I'm not a big fan of butchering
awesome productions with flangers or reverb so don't care much for effects...
maybe after I never have a key clash.
I'd be a lot more interested in novel user interfaces to navigate the music
library, f.ex. instantaneously calling up a full-screen, high-contrast 2+1/2d
overlay to zoom around styles, moods, etc., with visual cues, stuff that helps
improvise when a crowd inevitably isn't what you had planed: what drugs are
they on? where's my Shpongle crate?
cheers,
-- p
#!/usr/bin/env lua
--[[
Rumblepad event reader
]]
local
buttonTab = {}
local
axisNames = {lstick_x, lstick_y, rstick_x, rstick_y, hat_x, hat_y}
local
axisTab = {}
Init States ---
local
function InitStates()
for b = 1, 10 do
buttonTab[b] = 0
end
for a = 1, 7 do
axisTab[a] = 0
end
end
Get One event -
local
function GetOne(f)
--
-- [0; 1] timestamp
-- [2; 3] signature
-- [4; 5] word value (down/up for button, one axis value per axis
[Mixxx-devel] offline hardware controller driver development/unit-test
(splitting from 'hate Javascript' thread) Been wondering of a way to develop drivers offline, i.e. without physical access to a hardware controller. Right now only people who have physical access to the controller can write a driver, so 'owner' == 'coder', which is a huge limitation. Let's say those two roles can be reassigned to two different people: owner doesn't need to know coding, coder only needs to be talented. Advantages would be support for more devices, better drivers, porting drivers to a new architecture is a one-off, can be unit-tested against previous arch. Process would be a ping-pong like: - owner runs wizard app with UI to generate raw control data (a binary stream), sends file to coder - coder uses control data to write driver, sends driver to owner - owner tests driver, gives feedback - repeat This Driver Data Generator app, first asks owner to select a frontal image of the device, then walks through a series of dialogs for each device widget: - locate widget on bitmap with mouse click or rect select - type? (knob, fader, wheel, button, toggle, XY cursor) - subtype? (clamped, infinite, discrete) - name? (channel1 upfader, booth volume, deckAwheel) - calibrate - fiddle randomly during 10 seconds I looked at a bunch of hardware I have at home (DJM800, CDJ100, misc MIDI controllers), what would be the most exotic devices Mixxx already supports that'd complicate this procedure? Scratch is a special case that probably shouldn't go through any script anyway. -- p -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ 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
Re: [Mixxx-devel] Hate JavaScript and XML? ...then keep reading!
Hey, On Mon, 27 May 2013 03:14:50 -0400 RJ Ryan russelljryan-re5jqeeqqe8avxtiumw...@public.gmane.org wrote: 1) It's valuable to have a structured representation of the mappings. Code is a black box and Mixxx has no visibility into it. This means that mappings expressed purely in code are not manipulatable by Mixxx. It doesn't matter what the declarative format is (JSON, YAML, XML, etc.) So if this declarative table (which is obviously needed to standardize the glue interface) was returned from script itself that'd be ok right? After all Mixxx doesn't need it to be a disk file as long as it can retrieve a standard data structure. In that case driver writers could choose whatever storage they want if they're allergic to one file format or another. Switching to such an architecture just needs a standard Javascript function that loads existing XMLs. but a practical consideration is that breaking compatibility with the extensive set of controller scripts in the wild would be an extremely sub-optimal outcome. Agreed, it's a problem for many reasons. If you care about performance, you should instead be coming up with a standard, non-script way to implement scratching. Compared to executing code in a VM, the current XML bindings are orders of magnitude more efficient (It's a hash-map lookup to figure out which control to dispatch a message to). I only know how my own CDJ scratch works, it's a continuous stream of absolute timestamps. Post-processing the position deltas to detect play/pause/rew/ff/loop could probably be done in script. Are there other critical latency cases like resuming a cue to do a Roger Sanchez style needle-drop mix? (good luck:) 5) Controller scripts are a mechanism for advanced script authors to get full control and customization. Throwing out the mappings eliminates all possibility for non-advanced users to customize their controller without writing code. Does it make sense to separate/layer 'low-level driver' from higher-level customization, which could use a UI? cheers, -- p -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ 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
Re: [Mixxx-devel] offline hardware controller driver development/unit-test
On Mon, 27 May 2013 11:26:19 -0600 Neale Pickett neale-qiohqogmb3idnm+yrof...@public.gmane.org wrote: For a while, I was working with a guy in Spain (I'm in the United States) on a driver for his Hercules Steel. We were both on IRC, he ran a userspace program that interfaced with his controller with a TCP connection. I was able to ask him to hit buttons or slide controls over IRC, and the output came to me on the TCP connection. I could also send commands to the control over that same TCP connection, to try turning on lights or whatnot. Cool, did you use a generic MIDI over TCP encapsulator or something like usb2ip? Did you have plans to require less attention from the user? I'm guessing higher-end gear owners don't have as much time to spare or do you think that's not a problem? cheers, -- p -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ 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
Re: [Mixxx-devel] Hate JavaScript and XML? ...then keep reading!
On Sun, 26 May 2013 16:52:59 +0200
Juan Pedro Bolívar Puente raskolnikov-mXXj517/z...@public.gmane.org wrote:
I disagree.
I didn't mean to start a language pissing contest... but it looks like I did :)
First, there is nothing intrinsically more performant in Lua than in
JavaScript -- they are both dynamically typed languages with objects and
first-class functions. Also, there is a wide choice of VMs in in
Javascript. While QtScript uses the webkit JS engine, which is fairly
good and nothing prevents us to moving to V8 or something like that.
Javascript is performant in so far as it's JITed; there's LuaJIT too but I
don't recommend any type of JIT because it allocates a gigantic block of RAM
that's tagged as executable so it's harder to sandbox. JITs are largely
unnecessary if you identify functionality hotspots and can easily rewrite those
in C++, then expose those to the script layer.
Lua does not meet the realtime constraints neither anyway.
What makes you say that? I see you have experience in just about every
interpreter expect Lua (btw I live next door in Valencia if you want to take it
outside:).
Lua's used by Reason and ReNoise and in game engines since the PS2 all the way
to Crytek's Far Cry/Crysis which have similar frame-lock/tick constraints.
There's a laundry list of realtime apps on www.lua.org/uses.html. Most
tellingly, you'll find it in many embedded systems like Cisco, Barracuda,
MicroTik RouterOS, OpenWrt, Wavecom GSM firmware. It hardly gets more realtime
than that.
In my
experience, the scripting language should not be the fastest, but the
most expressive, because its goal is to allow very fast development and
hackability. If you look around, other music software are also using a
wide variety of similar approaches, like Ableton Live, which uses Python
(which is slower but more expressive than JS)
You would know so correct me if I'm wrong, aren't large parts of Live itself
written in Python? Lua is much nimbler and doesn't offer Python's richer object
orientation. In Mixxx's case, I understand the idea is extensibility - not to
rewrite large parts of the application in script.
What its missing in Mixxx is, however, an API in the scripting engine to
bind a MIDI signal to a control.
That's where Lua shines; writing a native Lua 'module' takes very few lines of
code. Lua is meant to be an embeddable language, i.e. it plugs into an existing
application vs the other way around, it's unobtrusive because it is so tiny.
This way, the script can handle mode
selection, but for every mode, the important MIDI messages (cue button,
knobs and faders) still go through the engine directly. Something like:
engine.connectMidiToControl(status, midino, group, control, options);
engine.connectControlToMidi(group, control, status, midino, options);
I wrote something like that and used it on all but my very first gigs. I
attached the glue code and script here; initialization is at the bottom. Please
don't judge Lua's merits (or mine for that matter:) based on this, it was never
meant to be used/seen by anyone but myself, is/was a work in progress and I
frequently tweaked scripts just before a gig, knowing full well it was pretty
risky/stupid.
If I were to critisize JavaScript, on the other hand, it would be
because it is not always as concise and expressive as it could be.
I'm fairly sure Lua is one of the most concise languages there is. Its
reference manual is 103 pages long, including the C API. Also Lua 5.2 has a
rich set of binary operators (for example bit range extract, ROL/ROR) that'd
help HID/MIDI processing.
cheers,
-- p
-- MIDIbots main lua scriptey
-- require Traktor313
-- MIDI NOTES START AT CONTROL 9 ?! (no fucking idea why)
-- device aliases (CACA -- MOVE TO SEPARATE INI -- different on each computer!)
dm2alias = SB Audigy MIDI Port II [A800]
traktoralias = MIDI Yoke NT: 1
-- some physical dj1 buttons are defined twice; once per selected deck
gDeckLUT = {[1] = deck_a, [2] = deck_b}
Variables
cueMode = auto
Shift = false
gSnapFlag = false
RebootCnt = 4
LastJoyLeftClock = 0
LastJoyRightClock = 0
LastJoyYTime = 0
ScanFlag = false
Wheel2for1 = false
WheelHadMod = false
LastDeckLoaded = -1
LockedDeck = -1
gDeck = {[1] = {TempoEditFlag = false, TempoPerc = 0}, [2] = {TempoEditFlag = false, TempoPerc = 0}}
gMaxTempoDelta = 40 -- not is up AND down
min, perc = mb.GetBatteryLevel()
print (battery = ..min.. minutes, ..perc..%%)
print(RECOMPILED NAKED SCRIPT!!!)
printf ---
function printf(fmt, ...)
local argtab = {...}
-- replace %S with %s
local expanded_fmt = string.gsub(fmt, %%S, \%%s\)
local s = string.format(expanded_fmt, unpack(argtab))
print(s)
end
Get Editd Deck -
local
function GetEditedDeck()
local edited_deck
Re: [Mixxx-devel] Hate JavaScript and XML? ...then keep reading!
This is a largely academic debate so apologies to other list readers for being off-topic. On Sun, 26 May 2013 21:47:45 +0200 Juan Pedro Bolívar Puente raskolnikov-mXXj517/z...@public.gmane.org wrote: What makes you say that? I see you have experience in just about every interpreter expect Lua (btw I live next door in Valencia if you want to take it outside:). I am based in Berlin now, so lets argue here instead :) So... Ableton or NI? I was offered a job but couldn't con them into telecommuting :) By real-time constraints I mean the real-time constraints that are usually required in the engine of most audio applications, which require algorithms to be O(bufferSize). Even non-GC heap allocations do not qualify for this, and because closures and dynamic typing can not be implemented without heap allocations (and GC) Lua has very fine-grained GC control otherwise it'd never run inside embedded devices or early-gen game consoles. To the extent modern C++ will have /some/ memory allocation (otherwise it's really ANSI C), good GC control may be even safer; it's easier to suspend/resume a VM if some time/CPU quota was reached than native code holding a mutex. Coders that design Lua-enabled engines take a simple perspective: what parts make sense in C/C++, what do in Lua. If some Lua logic become overwhelmed just move it to C++. In ~12 years of using Lua I came across a bottleneck only once (handling enormous flight-simulator samples); I moved that logic to a Lua C userdata in half an hour then it was solved. Now, a badly-written script driver can always do something stupid to abuse the VM but unlike web browsers, Mixxx isn't supposed to protect against hostile 3rd-party scripts. Although Wikipedia is switching to Lua and does provide such protections. I don't think one can run Lua code in the engine threads. Do you mean secondary threads? Lua can definitely do that; I wrote a TUIO extension that ran Lua in its own thread and Lua context, while the main thread ran another Lua context. IIRC TUIO is OSC (or MIDI?) over UDP so you can't afford to lose packets either. Also, Lua has 'coroutines' or cooperative multitasking so you can run multi-thread logic in a single OS thread; Lua 5.2 can yield across C boundaries too. I know it's an old concept but everybody went all oh and ah about Go's 'goroutines' (seriously). And if one can not run Lua code in the engine threads, there is going to be an added latency anyway to send the messages accross the engine boundaries, as long as the interpreter is not really bad, I do not think this is a big issue. There's always /some/ latency to the extent you're running any CPU instructions. Typically, Lua-based engines use custom data types whose memory layout is defined in C, so there's no significant memory juggling when crossing C/Lua boundaries or moving data from one Lua context to another. I would suggest you to take a look at asm.js, a subset of JavaScript used to compile new-generation C++ games to JavaScript that run at 2X the native version (and it is the whole game running in JS, even the engine!). I know asm.js but frankly using a LLVM backend is no different than JIT. Any scripting language that can allocate fill executable byte arrays could do the same, f.ex. the book Lua programming gems has a chapter using Fabrice Bellard's Tiny C Compiler (from boot-linux-from source code and Qemu fame) to embed native C code in Lua code. IMHO it's a pointless pursuit though; VMs should be sandboxed and prevented from generating new machine language at runtime. Lua's used by Reason and ReNoise and in game engines since the PS2 all the way to Crytek's Far Cry/Crysis which have similar frame-lock/tick constraints. There's a laundry list of realtime apps on www.lua.org/uses.html. Most tellingly, you'll find it in many embedded systems like Cisco, Barracuda, MicroTik RouterOS, OpenWrt, Wavecom GSM firmware. It hardly gets more realtime than that. Ok, that means its fast, but not real-time in the sense I mean, because they do not have a deadline. I know, you mean critical real-time. Or to put otherwise: in Far Cry if a single frame takes 50ms instead of an average of 16 (assuming 60fps) it will most probably go unnoticed. Nope it's exactly the same problem; both audio and video have the concept of frames. Missing a video monitor's vertical blank refresh (VBL) to draw a frame is like missing an audio frame; in one case you have tearing because it'll show an old frame, potentially very old since 3D cards are heavily pipelined with several pre-buffered frame, in the other you have a dropout or if the audio card's buffers are looping it'll click. In a professional application, video tearing is an unacceptable as audio dropouts. Video games have very large audiences and budgets, larger than Hollywood movies. Locking to a video frequency/bit-depth is as critical as it is for audio.
