#milkymist IRC log for Tuesday, 2011-11-01

wolfspraulwpwrak: wow I got a very positive answer from the faderfox guy01:14
wolfspraulunfortunately it needs more work to reply now :-)01:14
wolfspraulI will invite him to this channel etc.01:14
wolfspraullekernel_: would it help you if you got a LV3 test unit from faderfox.de ?01:18
wolfspraulthe guy suggested a demo unit swap, his whole response makes a lot of sense (unfortunately in German so I cannot easily forward/cc you)01:18
wolfspraulI will definitely find a way to get an M1 to him, and since he is offering a swap that's a perfect idea imho. but who would be the recipient of the LV3 ?01:19
wolfspraulit won't work right now because M1 does not have usb-midi...01:19
wolfspraulI think we should do this swap because it brings Milkymist and faderfox together, and the first step is always to start using products and talking to each other, then maybe later some ideas emerge on how the business could function.01:20
wolfspraulhe is currently working with modul8 to integrate some of his controllers with modul801:20
wolfspraulhe should definitely also integrate them with M1 :-)01:20
wpwrakhey, excellent !01:23
wolfspraulyes I forwarded you his reply01:27
wpwrakyou can still use it with M1 via a PC and a USB-MIDI adapter (see my post from today)01:27
wolfspraulalways good to find smart and reasonable and friendly people - SO RELAXING :-)01:27
wolfspraulI think we have to find more small businesses to work together01:27
wolfspraulsmall and professional01:27
wolfspraulthe idea of lobbying Roland or the likes into doing whatever with us can be done in parallel, but they move when they want to move01:28
wolfspraulanyway, need to be open-minded about *any* opportunity that opens up :-)01:29
wpwrakmaybe you can also share PR experience and such01:30
wolfspraulI am always and everywhere sharing "pr experience"01:32
wolfspraulbut let's not forget the most powerful tool at our disposal: the Internet01:32
wolfspraulhow did you find faderfox?01:32
wolfspraulyou have to get over the idea that there is some force somewhere controlling what becomes "famous" and what not01:33
wolfspraulbut the Internet really does give everybody fair and equal access and chance to be heard01:33
wolfspraulas long as you have access to the Internet, that is01:33
wolfspraulbut yes, we need to be smarter on how we tell our story, I agree01:33
wolfspraulyour videos are awesome, excellent, just fantastic :-)01:34
wolfspraulI'm scratching my head why it is always you leading :-) we need to find a way to clone Werner...01:34
wpwrakwow, very good reaction indeed01:35
wpwrak(find) hmm, not sure. i think i first googled for midi controllers and then came across ableton (DAW sw). they have a list of controllers they recommend01:36
wolfspraulok :-)01:36
wpwrakthe i went to all these manufacturer sites and looked for what else they had. sometimes googled for that, too. and occasionally came across something new yet again, which i then followed.01:37
wpwrakso somewhere in this recursive search, i came across faderfox :)01:37
wolfspraulthere are many more faderfoxes in the world01:38
wolfspraulto find them efficiently is another matter01:38
wolfspraulif we could just have a loudspeaker and blast all 7 billion people on Earth with a 1 hour marketing propaganda about how great m1 is, I am sure we would sell thousands today01:38
wolfspraulbut that's not how it works01:38
wpwraki also searched for anything "midi" controller on our local ebay clone01:39
wolfspraulactually I think in China, scary as that may be, they have a system of public loudspeakers that they can use to blast the entire billion, or large parts of them01:39
wolfspraulsay when one of their 'great leaders' dies01:39
wpwrak(blast all 7 billion) and a few million will probably want your head for this ;-)01:39
wolfspraulthey can play the same funeral songs *everywhere*01:39
wolfspraulit's scary01:39
wpwrakscary indeed01:39
wolfspraulin all factories, schools, transportation, subways, residential communities, streets, etc.01:40
wolfspraulmaybe we should hack into that and tell people about m1? :-)01:40
wpwrakthere may be such PA systems still in many countries that have had a history of air raids01:40
wpwrakyou would certainly earn some respect from lolsec, anonymous, etc. :)01:41
wolfspraulso anyway, the only realistic way for us to spread our message is to find more friends who help us carry the message further01:41
wolfspraulput links to milkymist onto their websites01:41
wolfspraultalk about it on blogs01:41
wolfspraulor if they are journalists write about it, mention it, comment on it, radio, magazine, etc.01:42
wolfspraulI think the conversion rates we see right now tell us we first have to fix something on our end01:42
wolfspraulSebastien converted 2800 visitors from ./ into 10 additional twitter followers :-)01:42
wolfspraulthe opposite of viral basically01:43
wolfspraulyour videos help a lot, really. at least me and Jon :-)01:44
wolfspraulI uploaded the 2nd one into the wiki http://en.qi-hardware.com/wiki/File:Werner_M1_MIDI_2.ogv01:44
wolfsprauland Xiangfu will get it into the milkymist youtube channel01:44
wpwrakkewl !01:44
wpwrakshall i remove the one with the non-free audio ?01:45
wolfspraulI didn't even know it was non-free01:45
wolfspraulwhat's the audio on the second one?01:45
wolfspraulsure we can delete the first video? I think the 2nd one supersedes it?01:46
wolfspraulyou tell me01:46
wolfspraulabout the green - I agree01:46
wolfspraulreally lopsided towards green01:46
wolfsprauland when the red and blue comes out it does look really cool01:46
wolfspraulso maybe increasing the color depth is a good idea (to remove the 5-6-5 rounding problems)01:46
wpwrakthe first one has "Last Jungle" by "Sub Focus" (non-free)01:47
wpwrakthe other has "Art Now" by Alex Beroza, featuring Snowflake01:47
wolfspraulfrom ccmixter?01:47
wpwrakCC-BY. all the details are in my post :) yes01:47
wolfsprauloh, post01:47
wolfspraulI will add that to the wiki page01:47
wpwrak(2nd video) i mean the 2nd with a proper audio track. there's also the one with the "technical" sound :)01:48
wpwrakMVI_1743.MOV is the one with "last jungle", MVI_1742.MOV is "technical", and the latest is MVI_1747.MOV with the cc-by track01:49
wolfspraulok I deleted the first one, and replaced with 174701:50
wpwraki'll delete it on downloads, too01:50
wpwrakgone :)01:51
wpwraki think it still lived on in sebastien's blog01:51
xiangfudeleted on youtube. :)01:52
wpwrakyeah, the new one is a worthy replacement. the first one was basically a rhapsody in green ;-)01:58
wpwraknow i need to see which usb cable i can pull without upsetting my little M1 universe ... for not being very good at USB, there's certainly quite a lot of USB stuff around it :)02:02
wpwrak(LV2 vs. LV3) my preference would be LV3, because it has a more generic layout and more controls, including a second joystick. but let's see what sebastien thinks02:14
wpwrakregarding controls in general, pads may indeed be better than joysticks, because they don't have the reset problem. but i haven't done anything really X/Y yet, so please take this with a grain of salt02:16
wpwrakand, and marketing "standalone" operation: maybe call it "auto-VJ", much like "auto-pilot". both can help take care of boring tasks, but they can't replace the human02:18
wpwrakthose midi hangs are nasty. luckily, it seems that you need a pretty good uptime to get them.03:08
wpwrakgrmbl. found a nice track ... and it's BY-NC :(03:09
wolfspraulcc is screwed03:18
wolfspraulthe -nc -nd poison is in there and just completely destroys any fun03:18
wpwrakat least ccmixter has "safe for commercial use". alas, they also include SAMPLING+ there03:19
lekernel_LV3, sure, why not08:02
lekernel_speaking about the crappy conversion rates, even the simple ad "M1 video synthesizer With camera for live video sampling No computer needed. Low latency. www.milkymist.org" didn't work on adwords08:02
lekernel_it had a very bad click-through rate, so there's already something wrong with this text08:02
wolfspra1llekernel_: ok, one by one. I will follow up with faderfox then and send the lv3 your way08:05
wolfspra1lI need a second m1 review unit with Tuxbrain asap08:06
wolfspra1lafter simon is done we need one for Thihi in Finland, and now also faderfox08:06
wolfspra1ladding up :-)08:06
lekernel_ah? I thought Tuxbrain already had two review units and only sent one08:07
wolfspra1lhe bought two08:07
lekernel_I'm talking about the reworked RC2 boards08:07
lekernel_the plan was to send him two, no?08:07
wolfspra1lthe second one is still in Taipei because the audio rework failed and Adam just exactly had 2 audio codecs left08:08
wolfspra1lbut hopefully we will get that one back as well08:08
wpwrak(nina) nice rant :)10:45
wpwraklekernel: that adwords as is quite a mouthful ;-)10:45
lekernelwpwrak, your modified "Tornado" patch looks great :)11:17
lekernelI can put it into the web update pool, if you want11:17
lekernel(and this will be an occasion for wolfspraul to test the web update *g*)11:18
wpwrakthanks ! :) it's amazing what a few controls can do11:18
lekernelbut you also changed the wave mode, no?11:18
wpwrakno, the wave mode is still the same11:18
lekernelah? interesting11:18
lekernelhow does it roll into those little balls then?11:18
lekernelit was a straight line before11:19
wpwrakthat's very low audio sensitivity11:19
lekernelper-vertex wizardry?11:19
wpwraknaw, just wave_scale dialed down to near-zero :)11:20
wpwrakhmm .. i guess when i attach ethernet, i'll be able to download my patch. haven't tried ether yet at all. let's make a cable ...11:31
lekernelyes, just obtain an IP address and set login/password for FTP ... and it should work11:38
lekernelall in the system settings dialog11:38
lekernel(this also enables a telnet server btw)11:38
wpwraknice :) that was easy12:08
wpwrakthis is my current version: http://downloads.qi-hardware.com/people/werner/m1/midi/x2.fnp12:16
wpwrakdiff from the original: http://pastebin.com/H8K1NDNa12:17
wpwrakhmm, the semicolon after wave_y is a typo. guess it doesn't hurt, though12:18
cxaMobileinteresting, apple keyboards don't work with the M1? lekernel wolfspraul17:02
kristianpaulcxaMobile: not, because they have a usb hub internally17:05
kristianpauland thats actually no suported by the system17:05
AndroUser2is there a completed manual for flickernoise?17:34
wpwraki don't think there's anything very complete. but the GUI isn't too hard to learn. it has a few quirks, but you'll figure them out. the manual for the patch language is work in progress and here:  http://downloads.qi-hardware.com/people/yi/flickernoise_handbook.pdf17:46
wpwrakit may look intimidatingly incomplete, but if analyzing what an existing patch does, i found it quite helpful17:47
lekernelwpwrak, memcpy (dst0=0x40a52dc4, src0=0x10, len0=4234967967) ?17:49
lekernelonly the first value looks legit here17:49
wpwrakoh, right. didn't spot his :)17:49
lekernelmaybe FN called rtems_message_queue_receive() with wrong parameters?17:49
wpwrakshouldn't src be from the message queue ?17:50
wpwrakwhich brings us back to the_message_queue->Pending_messages.first == -117:52
lekernelI'm not familiar enough with the RTEMS internals to know if this is a normal value or not17:55
lekernelmaximum_pending_messages = 64, number_of_pending_messages = 64,  should be ok, it just means that the queue is full17:56
wpwrakgot any RTEMS guru at hand ? :)17:56
wpwrak(queue full) yes. that's often when fencepost errors happen :)17:57
lekernelwhich could explain why the bug only triggers on large amounts of MIDI traffic: it would trigger on a full queue ...17:57
lekernelyou can try reducing the queue size, maybe that will make the bug more reproducible17:57
wpwrakthe bug also has another precursor: MIDI traffic slowing down rendering. that's how i can tell when it's time to kill the system.18:00
wpwrakmaybe the many lost MIDI messages are also somehow related to this. i guess i'll see when we've cracked the crash :)18:01
lekerneland is the rendering slowdown more frequent with a smaller queue?18:02
lekernelmaybe this is one single bug: when the queue is full, it smashes the stack or something like that18:03
lekernelsometimes it messes up with something that slows down rendering, sometimes it crashes completely18:03
wpwrakhmm, it feels more like the slowdown getting worse with time and when it's so bad that it won't recover from one burst before i turn around to send the next, i can make the buffer overrun18:04
wpwrakso there may be two connected problems: 1) something slowing down MIDI processing, and 2) things going seriously wrong once the queue is full18:05
wpwrakthere's a clear progression from normal (no perceptible slowing) to slight delay to increasing delay and finally long delay with hang18:07
wpwrakstrange. i see in init_input: rtems_message_queue_create(..., 48, ...)   not 64. well, maybe RTEMS gives you a few more entries than you ask for. or am i looking at the right queue ?18:15
wpwrakalas, input_q isn't a pointer18:15
wpwrakwhat do you suggest to do ?18:34
lekernelhmm seems there's no FN queue with 64 entries18:37
wpwrakah, and if your keyboard has a pot, encoder, fader, pad, or such, you may be able to reproduce the effect. it just takes time to happen.18:37
lekernelmaybe in the drivers18:37
lekernelit has, and it worked reliably for hours :-)18:37
scrtsmilkymist on XCell 77: http://www.xilinx.com/publications/archives/xcell/Xcell77.pdf18:38
scrtsdunno if anyone noticed18:38
scrtsor I am just too late :)18:38
wpwrakmine's been up for > 1 day. maybe that's the difference.18:38
lekernelyes, the MIDI driver uses a queue with 64 entries18:38
wpwraki don't know yet if the factor is uptime, rendering time, MIDI messages, or maybe sum of random events (greetings from the statistics :)18:39
wpwrakhah !18:39
wpwrakin which repo is that ? i don't seem to have it (yet)18:40
wpwrakah, the SDK conjured it up from somewhere18:43
wpwrakhmm, one interrupt per byte. that's must be rough on the CPU18:45
lekernelit's certainly inefficient, but as long as the volume of data is small, it's a good solution18:49
lekerneland even running at 31kbps sustained shouldn't have a large impact... unless there are bugs18:50
wpwraki would be more concerned about latency. is it guaranteed that your interrupt gets served within at most 250 us ?18:52
lekernelyeah, it should be fine... no heavy processing takes place with the interrupts disabled18:54
lekernelin either case, this would only cause lost bytes, not crashes or slowdowns18:54
wpwrakyes. i.e., it could explain all my lost MIDI messages :)18:54
lekernelyes, maybe, but I wouldn't jump to that conclusion :)18:55
wpwrakshould be easy to find out. any first byte without the MSB set would indicate trouble. now .. where is that midi queue emptied ...18:56
lekernelin input.c, where the serial stream is parsed, put into packets, and sent as "events"18:57
wpwrakah, i see18:57
wpwrakand who puts the MIDI messages into the input queue ?19:01
wpwrakseems that someone must somehow call midi_read and then stuff things into input_q19:02
wpwrakah, maybe input.c:event_task ?19:03
wpwraki see in midi_read that rtems_message_queue_receive doesn't seem to have a size limit19:04
wpwrakor maybe that's something inside buffer .. checking ...19:05
wpwrakno. that would probably be rw_args->count19:06
wpwrakah, but that's just one byte at a time19:09
wpwrakof course it means that we probably overrun the input queue19:10
wpwrakoh wow. you don't synchronize with the MIDI message stream ? that would explain quite a lot :)19:12
kristianpaulwhy not give more recurses to queue?19:12
wpwraknot the crash, though. but all those losses.19:12
wpwrakkristianpaul: i think that just makes it worse :)19:13
wpwrakthere's a lot of stuff that has to run for each byte. and we don't have the luxury of an insanely fast CPU where you sometimes can get away with such things19:14
wpwraki don't see the mechanism that makes things grow worse over time, though19:14
wpwrakokay, one bug is that lost bytes desynchronize the message stream. that means that you're okay only if you never lose a byte or if you lose a lot and have plenty of redundancy19:17
wpwrak(lose a lot) so that you keep on desyncronizing until you're - after two more lost bytes - synchronized again19:18
wpwrakthere's also a lot of casts in handle_midi_msg that look unnecessary19:20
lekernelthere's no way to synchronize in MIDI, except what is currently implemented - if nothing has been received for a while, assume the next byte is the first in a packet19:32
Last message repeated 1 time(s).19:35
lekernelwell, if you believe too much stuff is running for each byte, then flood the thing with a continuous stream of data (while the GUI is running, not rendering, so hopefully you don't run into the bug) and check CPU utilization from the shell19:35
lekerneleverything else is just guessing19:35
wpwrak(synchronize) i mean the MSB. that should be set in the first byte and 0 in all following bytes, no ?19:37
lekernelthis is 31kbps data at worst, not uncompressed video19:38
lekernelspending time on optimizations is welcome where it's needed19:38
wpwrakplus, there are also real-time messages that can be interleaved with other messages. not sure how common they are. but if they appear, they would have to be removed from the stream19:38
wpwrak(31 kbps) is's still one byte every 250 us = an interrupt and it seems two task switches19:39
lars_that's time 20000 instructions19:40
wpwrakfor high-volume stuff you typically have big FIFOs or even DMA. so most of the burden is on the memory subsystem, not so much on the CPU19:40
lekernel31kbps is nothing for the M1 memory system; however, DMA masters and FIFOs use developer time and FPGA resources19:41
lekerneland it seems you're right about that MSB thing. well, I must have read the wrong document. that deserves to be fixed.19:42
lekernelit's only the interrupt btw, the task switches won't necessarily happen for each byte. that's what the queues are for :)19:44
wpwrak(31 kpbs) oh sure, DMA would be overkill. a FIFO would be nice, though. or, better, build the messages "in hardware" and pass words containing full messages to the CPU. then you get only one interrupt per message, save a bit of processing, and you reduce badput twice: 1) by automatically filtering anything that already arrives with data loss, and 2) by never losing a message due to missing a byte19:45
lekernelso far the only problem I don't deny is the bug19:46
wpwrakthe currently high rate of message suggests that there already is a mechanism at work that makes the system miss things19:46
lekernel(and the MSB for sync)19:46
wpwrakall you need is one place that delays interrupts for a bit too long, and all falls apart19:46
wpwraks/currently high rate of message/\& losses/19:47
wpwrak(losses) they could of course have other causes than overloading. such as the interrupt not getting signaled properly, the UART missing something, or a problem upstream. still, such busy handlers are always suspect19:50
wpwrakokay, but none of this explains the hang, apparently with memory corruption19:51
wpwraklekernel: do you want me to fix the MIDI message synchronization ?19:57
kristianpaulmemory corruption? is not that *serious* ??20:00
wpwrakkristianpaul: hmm ? a mean corruption caused by sw. not by memory itself failing :)20:02
kristianpaulphew :)20:03
lars_if your memory is corrupt, you just have to pay it enough money and it will do whatever you want20:04
wpwrak(message loss) hmm, may be because of RT messages, such as the MIDI clock20:26
wpwrakthough that clock would tick at something like 50-150 Hz. high, but not terribly so. about 1/10 chance of hitting some other message20:29
wpwrak(besides SysEx, but we don't support those anyway)20:30
wpwraklekernel: so .. shall i hack on the MIDI processing ? if yes, i'll have to reset my hung M1. so if there's anything you want me to dump from it, i'd have to wait20:31
wpwrakgrmbl. coremsg.inl ... "we're too cool to just use .h, like everyone else" ? :-(20:43
wpwrakheh, nice. RTEMS seems to support multiprocessing20:49
wpwrak"It is deadly to block in an ISR." now, really ? ;-)20:54
wpwrak"typedef Chain_Control rtems_chain_control;", "typedef union ... Chain_Control;" ... sometimes, a mind it a terrible thing to make up :)21:10
wpwrakChain_Control looks a bit suspicious. there's one definition in cpukit/score/include/rtems/score/chain.h and another one in doc/tools/bmenu/chain.h21:14
wpwrakinterestingly, gdb says it's the latter that's being used21:14
wpwrakso either there's a lot more to documentation in RTEMS than meets the eye or something may have backfired a bit21:16
errordeveloperhm .. who's here is an rtems expert ?22:22
wpwraklekernel: i already fixed the MIDI problem. one interesting side-effect: it make sit a lot easier to reproduce the hang ;-)23:32
lekernelthe sync problem?23:47
Action: lekernel is just back from the pub23:48
wpwrakhehe ;-)23:48
wpwrakyes, the sync problem23:48
wpwrakhmm, i need to improve my melt-foo. tried to convert the video to .ogg but the result stinks. and mencoder doesn't seem to want to have anything to do with ogg23:50
Thihi.ogm surely?23:53
GitHub50[flickernoise] sbourdeauducq pushed 1 new commit to stable_1.0: http://git.io/WbgzLw23:54
GitHub50[flickernoise/stable_1.0] input.c: remove unnecessary casts - Werner Almesberger23:54
GitHub152[flickernoise] sbourdeauducq pushed 2 new commits to master: http://git.io/JG5HUg23:55
GitHub152[flickernoise/master] input.c: remove unnecessary casts - Werner Almesberger23:55
GitHub152[flickernoise/master] Merge branch 'master' of github.com:milkymist/flickernoise - Sebastien Bourdeauducq23:55
--- Wed Nov 2 201100:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!