=== eu is now known as Guest24989 [08:44] Good morning all, happy Youth Day! :-D === karni_ is now known as karni === karni is now known as Guest5198 === Guest5198 is now known as karni_ === karni_ is now known as karni === wedgwood is now known as Guest52531 === eu is now known as Guest74187 === pedronis_ is now known as pedronis === Guest52531 is now known as wedgwood [14:25] o hai dobey :) [14:25] hey [14:26] how's it going? [14:26] ok [14:26] you? [14:26] actually, pretty well, modulo annoyance that porting C to JS is harder than I was hoping it would be :) [14:27] you're rewriting some C code in JS? [14:28] ya. Echonest's song recogniser, echoprint, is open source, which is rather nice. But I don't want native code; I figured it'd be doable to port the recogniser to pure client-side JavaScript; then I could have something shazamish without compilation and cross-platform. [14:28] (ignore, for the moment, how you get the song data *into* the browser; that's doable with the web audio API) [14:29] I could use emscripten or something to compile the C to JS, but that seems massively overkill; it's just doing manipulation on arrays of numbers, so I thought I'd reimplement it in JS. [14:29] (also, emscripten assumes you know a lot more about C than I do.) [14:29] is there a C lib too? i thought it was C++ [14:30] C++, sorry [14:30] the recogniser has three stages: whiten, subband analysis, and creating the fingerprint. The first two stages were fine -- the meat of the code is practically unchanged between C and JS (as I say, it's just doing operations on a big array of numbers, even if that big array in C++ is actually a block of memory) [14:31] the third stage, fingerprinting... it's confusing me, 'cos the code does C-ish things like index into an array with a negative index...which is obviously fine in C, where it's all just pointers under the covers, but not at all fine in JS, where arrays are a real thing rather than just syntactic sugar for memory access. [14:31] that means I have to understand what the code's doing, not just blindly port it...and that's hard. Or it's hard for me, anyway :) [14:33] uh, negative index in C is not fine [14:33] dobey, I invite you to consider https://github.com/echonest/echoprint-codegen/blob/master/src/Fingerprint.cxx#L115 [14:34] aquarius: negative index in C results in undefined behavior [14:35] j loops from 0 up to SUBBANDS. k loops from 0 up to nbn. Thus, pE[j-SUBBANDS*k] is pE[ (a number smaller than SUBBANDS) - SUBBANDS * (a positive number) ]. [14:35] a[-1] /may/ give you the last element of a[], but i don't think it is guaranteed to do so [14:35] I can't see how that's anything other than negative? [14:36] right. i didn't say that the code wasn't doing that. i said it's undefined. i also don't know what SUBBANDS is. [14:36] defined as 8 [14:36] this sort of thing is why I'm finding this difficult :) [14:38] originally I was pinging you about the whole call-this-library-from-ctypes-so-I-can-write-a-test-suite thing [14:38] right [14:39] but in the end you convinced me that that was either hard or impossible, so I just dropped a load of print statements into the executable and ran the executable and piped the output to a text file, and then parsed the text file from js to write the test suite :) [14:40] http://stackoverflow.com/questions/4006736/c-negative-array-index [14:40] i don't think c++ defines arrays differently, but it might [14:43] right. [14:43] so that code in echoprint is buggy [14:43] I have tweeted at the echonest people to whine at them [14:44] for extra hilarity, JS appears to be treating floating point stuff with different precision than C++ does, but I have decided to ignore that for now -- the numbers come up pretty close to being the same, and I'm secretly hoping that that means that the fingerprints will be the same [14:44] if it doesn't mean that, then I get to cry and go back and fix that, but that sounds like major hassle :) [14:45] oh yeah, floating point. fun times that [14:45] you're probably going to be crying :) [14:48] right :) [14:49] but the fingerprint code is what's killing me right now. I was really hoping to not have to walk through it line-by-line by hand and understand it all :( [14:49] all the variables being called stuff like Eb and pE is not helping, I have to say. [14:49] i don't see any other way. especially given their variable names [14:49] heh [14:49] * aquarius grins [14:49] I presume Eb is some sort of class though [14:50] tbh the goal was to have something shazamish on Ubuntu, but it's not clear to me whether the Touch browser will support modern stuff like the web audio API anyway; the Qt WebKit implementation is quite a way behind on this sort of thing [14:51] meaning that this little project is very rapidly approaching the tipover point away from "that'd be a fun little hack" into "the hell with this hard work, I have paid things to do" :) [14:51] i suppose it wouldn't be terribly hard to write an echoprint app in C++ though [14:52] aside from the fact that code is apparently buggy [14:53] does echoprint-codegen have a testsuite itself that's easy to run from "make test" or something? [14:57] hahahahahaha [14:57] was afraid of that [14:57] aquarius@faith:~/Programs/Others/echoprint/echoprint-codegen/src$ grep test * [14:57] AudioStreamInput.cxx: // Not an exhaustive list. ogg and rm could be added if tested. [14:57] grep: echoprint-codegen-ios: Is a directory [14:57] no. :-) [14:58] i got that much from the maniacal laughter [14:59] it wouldn't be hard to write a C++ app -- just use the library [14:59] but I'm not interested in C++ :-) [15:00] someone else could do that, though [15:00] elleomea wrote "eyrie" for the N9 a while back which does this, so that should be even easier to port. [15:02] a test suite would be nice though; then i could set up a daily build which runs the tests on arm, i386, and amd64 === eu is now known as Guest41424