<wolfspraul>
wpwrak: wow I got a very positive answer from the faderfox guy
<wolfspraul>
unfortunately it needs more work to reply now :-)
<wolfspraul>
I will invite him to this channel etc.
<wolfspraul>
lekernel_: would it help you if you got a LV3 test unit from faderfox.de ?
<wolfspraul>
the guy suggested a demo unit swap, his whole response makes a lot of sense (unfortunately in German so I cannot easily forward/cc you)
<wolfspraul>
I 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 ?
<wolfspraul>
it won't work right now because M1 does not have usb-midi...
<wolfspraul>
I 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.
<wolfspraul>
he is currently working with modul8 to integrate some of his controllers with modul8
<wolfspraul>
he should definitely also integrate them with M1 :-)
<wpwrak>
hey, excellent !
<wolfspraul>
yes I forwarded you his reply
<wpwrak>
you can still use it with M1 via a PC and a USB-MIDI adapter (see my post from today)
<wolfspraul>
always good to find smart and reasonable and friendly people - SO RELAXING :-)
<wolfspraul>
I think we have to find more small businesses to work together
<wolfspraul>
small and professional
<wolfspraul>
the idea of lobbying Roland or the likes into doing whatever with us can be done in parallel, but they move when they want to move
<wolfspraul>
anyway, need to be open-minded about *any* opportunity that opens up :-)
<wpwrak>
maybe you can also share PR experience and such
<wolfspraul>
he
<wolfspraul>
I am always and everywhere sharing "pr experience"
<wolfspraul>
but let's not forget the most powerful tool at our disposal: the Internet
<wolfspraul>
:-)
<wolfspraul>
how did you find faderfox?
<wolfspraul>
google?
<wolfspraul>
you have to get over the idea that there is some force somewhere controlling what becomes "famous" and what not
<wolfspraul>
but the Internet really does give everybody fair and equal access and chance to be heard
<wolfspraul>
as long as you have access to the Internet, that is
<wolfspraul>
but yes, we need to be smarter on how we tell our story, I agree
<wolfspraul>
your videos are awesome, excellent, just fantastic :-)
<wolfspraul>
I'm scratching my head why it is always you leading :-) we need to find a way to clone Werner...
<wpwrak>
wow, very good reaction indeed
<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 recommend
<wolfspraul>
ok :-)
<wpwrak>
the 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.
<wpwrak>
so somewhere in this recursive search, i came across faderfox :)
<wolfspraul>
:-)
<wolfspraul>
there are many more faderfoxes in the world
<wolfspraul>
but...
<wolfspraul>
to find them efficiently is another matter
<wolfspraul>
if 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 today
<wolfspraul>
but that's not how it works
<wpwrak>
i also searched for anything "midi" controller on our local ebay clone
<wolfspraul>
actually 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 them
<wolfspraul>
say when one of their 'great leaders' dies
<wpwrak>
(blast all 7 billion) and a few million will probably want your head for this ;-)
<wolfspraul>
they can play the same funeral songs *everywhere*
<wolfspraul>
it's scary
<wpwrak>
scary indeed
<wolfspraul>
in all factories, schools, transportation, subways, residential communities, streets, etc.
<wolfspraul>
maybe we should hack into that and tell people about m1? :-)
<wpwrak>
there may be such PA systems still in many countries that have had a history of air raids
<wpwrak>
you would certainly earn some respect from lolsec, anonymous, etc. :)
<wolfspraul>
so anyway, the only realistic way for us to spread our message is to find more friends who help us carry the message further
<wolfspraul>
put links to milkymist onto their websites
<wolfspraul>
talk about it on blogs
<wolfspraul>
or if they are journalists write about it, mention it, comment on it, radio, magazine, etc.
<wolfspraul>
I think the conversion rates we see right now tell us we first have to fix something on our end
<wolfspraul>
Sebastien converted 2800 visitors from ./ into 10 additional twitter followers :-)
<wolfspraul>
the opposite of viral basically
<wolfspraul>
antiseptical
<wolfspraul>
your videos help a lot, really. at least me and Jon :-)
<wpwrak>
i think it still lived on in sebastien's blog
<xiangfu>
deleted on youtube. :)
<wpwrak>
yeah, the new one is a worthy replacement. the first one was basically a rhapsody in green ;-)
<wpwrak>
now 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 :)
<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 thinks
<wpwrak>
regarding 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 salt
<wpwrak>
and, 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 human
<wpwrak>
those midi hangs are nasty. luckily, it seems that you need a pretty good uptime to get them.
<wpwrak>
grmbl. found a nice track ... and it's BY-NC :(
<wolfspraul>
yeah
<wolfspraul>
cc is screwed
<wolfspraul>
the -nc -nd poison is in there and just completely destroys any fun
<wpwrak>
at least ccmixter has "safe for commercial use". alas, they also include SAMPLING+ there
<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 adwords
<lekernel_>
it had a very bad click-through rate, so there's already something wrong with this text
<wolfspra1l>
lekernel_: ok, one by one. I will follow up with faderfox then and send the lv3 your way
<wolfspra1l>
I need a second m1 review unit with Tuxbrain asap
<wolfspra1l>
after simon is done we need one for Thihi in Finland, and now also faderfox
<wolfspra1l>
adding up :-)
<lekernel_>
ah? I thought Tuxbrain already had two review units and only sent one
<wolfspra1l>
he bought two
<lekernel_>
I'm talking about the reworked RC2 boards
<lekernel_>
the plan was to send him two, no?
<wolfspra1l>
the second one is still in Taipei because the audio rework failed and Adam just exactly had 2 audio codecs left
<wolfspra1l>
but hopefully we will get that one back as well
<wpwrak>
(nina) nice rant :)
<wpwrak>
lekernel: that adwords as is quite a mouthful ;-)
<wpwrak>
s/as/ad/
<lekernel>
wpwrak, your modified "Tornado" patch looks great :)
<lekernel>
I can put it into the web update pool, if you want
<lekernel>
(and this will be an occasion for wolfspraul to test the web update *g*)
<wpwrak>
thanks ! :) it's amazing what a few controls can do
<lekernel>
but you also changed the wave mode, no?
<wpwrak>
no, the wave mode is still the same
<lekernel>
ah? interesting
<lekernel>
how does it roll into those little balls then?
<lekernel>
it was a straight line before
<wpwrak>
that's very low audio sensitivity
<lekernel>
per-vertex wizardry?
<wpwrak>
naw, just wave_scale dialed down to near-zero :)
<wpwrak>
hmm .. 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 ...
<lekernel>
yes, just obtain an IP address and set login/password for FTP ... and it should work
<lekernel>
all in the system settings dialog
<lekernel>
(this also enables a telnet server btw)
<wpwrak>
hmm, the semicolon after wave_y is a typo. guess it doesn't hurt, though
<cxaMobile>
interesting, apple keyboards don't work with the M1? lekernel wolfspraul
<kristianpaul>
cxaMobile: not, because they have a usb hub internally
<kristianpaul>
and thats actually no suported by the system
<AndroUser2>
is there a completed manual for flickernoise?
<wpwrak>
i 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.pdf
<wpwrak>
it may look intimidatingly incomplete, but if analyzing what an existing patch does, i found it quite helpful
<lekernel>
maybe FN called rtems_message_queue_receive() with wrong parameters?
<wpwrak>
shouldn't src be from the message queue ?
<lekernel>
probably
<wpwrak>
which brings us back to the_message_queue->Pending_messages.first == -1
<lekernel>
I'm not familiar enough with the RTEMS internals to know if this is a normal value or not
<lekernel>
maximum_pending_messages = 64, number_of_pending_messages = 64,  should be ok, it just means that the queue is full
<wpwrak>
got any RTEMS guru at hand ? :)
<wpwrak>
(queue full) yes. that's often when fencepost errors happen :)
<lekernel>
which could explain why the bug only triggers on large amounts of MIDI traffic: it would trigger on a full queue ...
<lekernel>
you can try reducing the queue size, maybe that will make the bug more reproducible
<wpwrak>
the bug also has another precursor: MIDI traffic slowing down rendering. that's how i can tell when it's time to kill the system.
<wpwrak>
maybe the many lost MIDI messages are also somehow related to this. i guess i'll see when we've cracked the crash :)
<lekernel>
and is the rendering slowdown more frequent with a smaller queue?
<lekernel>
maybe this is one single bug: when the queue is full, it smashes the stack or something like that
<lekernel>
sometimes it messes up with something that slows down rendering, sometimes it crashes completely
<wpwrak>
hmm, 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 overrun
<wpwrak>
so there may be two connected problems: 1) something slowing down MIDI processing, and 2) things going seriously wrong once the queue is full
<wpwrak>
there's a clear progression from normal (no perceptible slowing) to slight delay to increasing delay and finally long delay with hang
<wpwrak>
strange. 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 ?
<wpwrak>
alas, input_q isn't a pointer
<wpwrak>
what do you suggest to do ?
<lekernel>
hmm seems there's no FN queue with 64 entries
<wpwrak>
ah, 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.
<lekernel>
maybe in the drivers
<lekernel>
it has, and it worked reliably for hours :-)
<wpwrak>
i don't know yet if the factor is uptime, rendering time, MIDI messages, or maybe sum of random events (greetings from the statistics :)
<wpwrak>
hah !
<wpwrak>
in which repo is that ? i don't seem to have it (yet)
<wpwrak>
ah, the SDK conjured it up from somewhere
<wpwrak>
hmm, one interrupt per byte. that's must be rough on the CPU
<lekernel>
it's certainly inefficient, but as long as the volume of data is small, it's a good solution
<lekernel>
and even running at 31kbps sustained shouldn't have a large impact... unless there are bugs
<wpwrak>
i would be more concerned about latency. is it guaranteed that your interrupt gets served within at most 250 us ?
<lekernel>
yeah, it should be fine... no heavy processing takes place with the interrupts disabled
<lekernel>
in either case, this would only cause lost bytes, not crashes or slowdowns
<wpwrak>
yes. i.e., it could explain all my lost MIDI messages :)
<lekernel>
yes, maybe, but I wouldn't jump to that conclusion :)
<wpwrak>
should be easy to find out. any first byte without the MSB set would indicate trouble. now .. where is that midi queue emptied ...
<lekernel>
in input.c, where the serial stream is parsed, put into packets, and sent as "events"
<wpwrak>
ah, i see
<wpwrak>
and who puts the MIDI messages into the input queue ?
<wpwrak>
seems that someone must somehow call midi_read and then stuff things into input_q
<wpwrak>
ah, maybe input.c:event_task ?
<wpwrak>
i see in midi_read that rtems_message_queue_receive doesn't seem to have a size limit
<wpwrak>
or maybe that's something inside buffer .. checking ...
<wpwrak>
no. that would probably be rw_args->count
<wpwrak>
ah, but that's just one byte at a time
<wpwrak>
of course it means that we probably overrun the input queue
<wpwrak>
oh wow. you don't synchronize with the MIDI message stream ? that would explain quite a lot :)
<kristianpaul>
why not give more recurses to queue?
<wpwrak>
not the crash, though. but all those losses.
<wpwrak>
kristianpaul: i think that just makes it worse :)
<wpwrak>
there'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 things
<wpwrak>
i don't see the mechanism that makes things grow worse over time, though
<kristianpaul>
;)
<wpwrak>
okay, 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 redundancy
<wpwrak>
(lose a lot) so that you keep on desyncronizing until you're - after two more lost bytes - synchronized again
<wpwrak>
there's also a lot of casts in handle_midi_msg that look unnecessary
<lekernel>
there'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 packet
<lekernel>
well, 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 shell
<lekernel>
everything else is just guessing
<wpwrak>
(synchronize) i mean the MSB. that should be set in the first byte and 0 in all following bytes, no ?
<lekernel>
this is 31kbps data at worst, not uncompressed video
<lekernel>
spending time on optimizations is welcome where it's needed
<lekernel>
really?
<lekernel>
mh
<wpwrak>
plus, 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 stream
<wpwrak>
(31 kbps) is's still one byte every 250 us = an interrupt and it seems two task switches
<lars_>
that's time 20000 instructions
<wpwrak>
for 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 CPU
<lekernel>
31kbps is nothing for the M1 memory system; however, DMA masters and FIFOs use developer time and FPGA resources
<lekernel>
and it seems you're right about that MSB thing. well, I must have read the wrong document. that deserves to be fixed.
<lekernel>
it's only the interrupt btw, the task switches won't necessarily happen for each byte. that's what the queues are for :)
<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 byte
<lekernel>
so far the only problem I don't deny is the bug
<wpwrak>
the currently high rate of message suggests that there already is a mechanism at work that makes the system miss things
<lekernel>
(and the MSB for sync)
<wpwrak>
all you need is one place that delays interrupts for a bit too long, and all falls apart
<wpwrak>
s/currently high rate of message/\& losses/
<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 suspect
<wpwrak>
okay, but none of this explains the hang, apparently with memory corruption
<wpwrak>
lekernel: do you want me to fix the MIDI message synchronization ?
<kristianpaul>
memory corruption? is not that *serious* ??
<wpwrak>
kristianpaul: hmm ? a mean corruption caused by sw. not by memory itself failing :)
<kristianpaul>
phew :)
<lars_>
if your memory is corrupt, you just have to pay it enough money and it will do whatever you want
<wpwrak>
(message loss) hmm, may be because of RT messages, such as the MIDI clock
<wpwrak>
though that clock would tick at something like 50-150 Hz. high, but not terribly so. about 1/10 chance of hitting some other message
<wpwrak>
(besides SysEx, but we don't support those anyway)
<wpwrak>
lekernel: 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 wait
<wpwrak>
grmbl. coremsg.inl ... "we're too cool to just use .h, like everyone else" ? :-(
<wpwrak>
heh, nice. RTEMS seems to support multiprocessing
<wpwrak>
"It is deadly to block in an ISR." now, really ? ;-)
<wpwrak>
"typedef Chain_Control rtems_chain_control;", "typedef union ... Chain_Control;" ... sometimes, a mind it a terrible thing to make up :)
<wpwrak>
Chain_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.h
<wpwrak>
interestingly, gdb says it's the latter that's being used
<wpwrak>
so either there's a lot more to documentation in RTEMS than meets the eye or something may have backfired a bit
<errordeveloper>
hm .. who's here is an rtems expert ?
<wpwrak>
lekernel: i already fixed the MIDI problem. one interesting side-effect: it make sit a lot easier to reproduce the hang ;-)
<lekernel>
the sync problem?
<lekernel>
is just back from the pub
<wpwrak>
hehe ;-)
<wpwrak>
yes, the sync problem
<wpwrak>
hmm, 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 ogg
<Thihi>
.ogm surely?
<GitHub50>
[flickernoise] sbourdeauducq pushed 1 new commit to stable_1.0: http://git.io/WbgzLw
<GitHub50>
[flickernoise/stable_1.0] input.c: remove unnecessary casts - Werner Almesberger
<GitHub152>
[flickernoise] sbourdeauducq pushed 2 new commits to master: http://git.io/JG5HUg
<GitHub152>
[flickernoise/master] input.c: remove unnecessary casts - Werner Almesberger
<GitHub152>
[flickernoise/master] Merge branch 'master' of github.com:milkymist/flickernoise - Sebastien Bourdeauducq