Topic for #milkymist is now Milkymist One, Milkymist SoC & Flickernoise development channel (LLHDL/Antares are welcome too) :: Logs: http://en.qi-hardware.com/mmlogs :: JFDI
<kristianpaul>
nah,
<kristianpaul>
yes that will be great to know how, as i can eliminate and excesive number of debug signal on namuru...
<wpwrak>
just doing a bit of cleanup, more testing, and integration
<kristianpaul>
i'll eliminate some signals for now then ;-)
cxadams joined #milkymist
wpwrak joined #milkymist
<wpwrak>
now, let's try to swap some pins and see what happens
_whitelogger joined #milkymist
Topic for #milkymist is now Milkymist One, Milkymist SoC & Flickernoise development channel (LLHDL/Antares are welcome too) :: Logs: http://en.qi-hardware.com/mmlogs :: JFDI
Technicus joined #milkymist
xiangfu joined #milkymist
rejon joined #milkymist
n0carri3r joined #milkymist
<n0carri3r>
evening all
<wpwrak>
hey vj ! :) how was the great M1 tour ?
<n0carri3r>
haha
<n0carri3r>
things went well - used it a few times lately!
<wolfspraul>
using a usb-midi controller and (small) graphics
<wolfspraul>
both is still quite hacked up but hopefully getting to really usable soon
<wpwrak>
(small graphics) i realize that, while the heavily pixelated effect is intentional, it may lead to misunderstandings :)
<n0carri3r>
ahh cool
<n0carri3r>
can't wait for that stuff, really!
<wpwrak>
n0carri3r: i wonder how you controlled the M1, e.g., to adjust audio sensitivity and such, maybe even patch parameters. e.g., did you use MIDI controls ?
<n0carri3r>
MIDI-USB will be great
<wpwrak>
everyone wants that :)
<n0carri3r>
i made multiple copies of patches bound to different keys with slightly different variables
<n0carri3r>
since i didnt have USBMIDI :)
<wpwrak>
heh :)
cxadams joined #milkymist
<wpwrak>
what already works is going via a PC: USB-MIDI -> PC -> USB-MIDI-dongle -> M1
<n0carri3r>
yeah
<wpwrak>
or USB-MIDI -> PC -> OSC/ethernet -> M1
<wpwrak>
what midi controllers do you use or plan to use ?
<n0carri3r>
my roommate has a few of the korg nano controllers
<n0carri3r>
so maybe using pads to toggle effects and some sliders/pots to fine tune variables
<n0carri3r>
that way i could have less key bindings
<wpwrak>
the nanoKONTROL2 has a number of sliders and pots, plus a lot of buttons
<n0carri3r>
also, any change to bind patches to the numeric pad?
<wpwrak>
(1st video) pretty cool. the effects work very well
<n0carri3r>
yes, when you see the direction of the swirls change, its different patches
<n0carri3r>
with MIDI control
<n0carri3r>
it wouldnt have to be
<wpwrak>
(2nd vid) heh, so that's what a drug trip going to hell looks like ;-)
<n0carri3r>
haha yep
<wpwrak>
very nice menacing effect :)
<n0carri3r>
they are a kind of psychedelic chip music act
<n0carri3r>
so all live instruments and game boy backing track
<n0carri3r>
anyway, no lock ups or freezes for me!
<n0carri3r>
but i will update anyway :)
<kristianpaul>
can not wait for image support? :)
<n0carri3r>
wait, is image support in the new update
<n0carri3r>
?
<kristianpaul>
i think no yet
<n0carri3r>
i thought it was just on the git, but not complied yet
<n0carri3r>
compiled*
<kristianpaul>
yes
<n0carri3r>
yeah, image support & MIDIUSB will be great
<wpwrak>
usb-midi is still some days away. first, full-speed usb needs to get a bit more reliable
<wpwrak>
it's actually at a point where i can use my hhkb. but i think sebastien has a device that still doesn't even enumerate. haven't tried my MIDI critters yet
<wpwrak>
i kinda wonder how far we can push midi control complexity. the faderfox lv3 has about 54 distinct controls, without counting shift (well, 8 or them are a fancy radio button)
<wolfspraul>
wpwrak: oh, usb full-speed is already that advanced? so basically it does work to a degree now?
<n0carri3r>
kristian: yes, a computer. those arent my visuals, though
<wpwrak>
the nanoKONTROL2 has around 50 controls
<wpwrak>
wolfspraul: the improved dpll brought down the error rate a lot
<wolfspraul>
do we have a feeling where the remaining degree of non-workingness will come from? software, hardware?
<wpwrak>
it still complains about every 5-10 seconds, but nothing compared to the stream of nasty corruptions i got before
<wolfspraul>
I asked Adam to be on the lookout for a good scope to measure the analog signals, if he finds something at a shop he is going to anyway (xray etc)
<wpwrak>
probably software. i'm a lot less worried about hardware now
<wolfspraul>
but you still route your lv3 through the computer - why?
<wolfspraul>
does the full-speed part of that work now on m1?
<kristianpaul>
wpwrak: but i heard crc in hardware may solve some issues that sofware may be generating, right?
<kristianpaul>
i mean for usb
<wpwrak>
oh, with the LV3 there are even two good reasons: 1) no usb-midi protocol support in M1 2) the LV3 has some wicked mappings that are very different from what flickernoise expects
<wpwrak>
(crc) the crc will make things perfect :) right now, i'm after those rx timeouts. well, once i'm done with the taps.
<kristianpaul>
yes, taps firsrt :)
<wpwrak>
kristianpaul: did you see that i already committed the functions that modify the .xdl ?
<kristianpaul>
yes
<kristianpaul>
n0carri3r: the others band at 8static did said something about M1 you think is worth to mention?
<n0carri3r>
you mean, what did they think of it?
<kristianpaul>
yes
<n0carri3r>
everyone at the gigs where i've used it have been very impressed
<n0carri3r>
at the capibilities, the price, etc.
<n0carri3r>
a good friend of mine, an engineer, really likes it - and he works on FPGA's himself, so he was interested in the hardware
<wpwrak>
excellent ! wolfspraul: how many left in stock ? :)
<kristianpaul>
wpwrak: and i'll try it soon i need to verify namuru timing sample is in sycn with sige's receiver clock
<kristianpaul>
wpwrak: i guess can tap more than one signal with no problem?
<wolfspraul>
n0carri3r: hmm, how do we convert these people from saying 'great' to becoming active? :-)
<wpwrak>
up to twelve should be fine. then you need to find some pads you can scrifice
<n0carri3r>
you mean other VJ's?
<wolfspraul>
should we follow up with the engineer?
<wolfspraul>
no the excitement you just mentioned
<wpwrak>
(twelve) i.e., the exp<*> group on J21
<kristianpaul>
sure i already have wires in that one
<wolfspraul>
do we appear friendly and approachable? :-)
<n0carri3r>
haha i'm sure
<n0carri3r>
i dont thats a problem :)
<n0carri3r>
i saw you post about something cheaper, like a $99 item?
<n0carri3r>
(on twitter)
<wolfspraul>
Sebastien talked about that, yes
<wpwrak>
which is a polite way of saying that nobody else saw much sense in it ;-)
<wpwrak>
there are actually two problems with the idea: 1) you can't go that low without selling directly at a loss. 2) it would be a major effort to design such a simplified board.
<wpwrak>
what could be done are reduced versions of the regular M1 board. or boards with well-understood and isolated defects
<wpwrak>
targeted at developers. but ... we'd have to be very careful not to make this compete with the regular M1
<wolfspraul>
n0carri3r: ok if there is anyone I can follow up with regarding m1, let me know
<wolfspraul>
if they have no problem with chatting, a very good starting point is also this channel
<stekern>
hmm, my M1 doesn't seem to like that I tinkered with it
<wolfspraul>
stekern: what happened?
<stekern>
I reflashed it with my stuff, but flickernoise didn't boot with that, so I tried reflashing with the "release" but that just stops with the two left LEDS dimmed
<stekern>
reflashing my build back gets me the bios though
<stekern>
but with USB errors
<xiangfu>
stekern, ( I tried reflashing with the "release" but that just stops with the two left LEDS ) stop when reflash? or boot?
<xiangfu>
are you using reflash_m1.sh?
<stekern>
xiangfu: yes, that one for the "release"
<stekern>
it ends up like that right after power is applied
<stekern>
reflashing just the soc.fpg gets me into bios
<stekern>
the soc.fpg I built that is
<wolfspraul>
maybe you are running into your very first own bugs! ;-)
<wolfspraul>
welcome to the club
<wolfspraul>
Werner has been through that how many times now? wpwrak ? :-)
<stekern>
yeah, stuff that just works are no fun ;)
<wolfspraul>
you will hardly be able to sit on your chair by the sheer energy of joy coming out of your m1
<stekern>
it did work fine until I started touching it though :)
<wolfspraul>
m1 hacker is a different level of hacker
<wolfspraul>
so...
<wolfspraul>
we've seen this type of various DIM lit states a lot
<wolfspraul>
and fixes lots of bugs
<wolfspraul>
but maybe there are more
<wolfspraul>
and/or software/bitstream could be more robust
<stekern>
how can I (if I can) change the IP in bios?
<wolfspraul>
when you go back to the release image, try unplugging your dc cable and wait for 10 minutes
<wolfspraul>
just to establish a testing baseline
<stekern>
I think I did that, but will try that
<stekern>
got to run, bbl
<wolfspraul>
cya
<wpwrak>
wolfspraul: hmm, a few times :)
<wolfspraul>
I'm wondering what happened
<wolfspraul>
could be a lot of things
<wolfspraul>
are the leds dimly lit or fully lit
<wolfspraul>
usb transmission problem
<wolfspraul>
maybe just didn't wait long enough for boot?
<wolfspraul>
problem with the bitstream he built himself
<wpwrak>
my guess would be some version conflict. e.g., soc and FN disagreeing on the hw interface
<wolfspraul>
but going back to reflash_ben also didn't work
<wpwrak>
oh, and i think a full reset by power cycling takes about one second :)
<wolfspraul>
maybe several small issues or knowledge traps
<wpwrak>
hmm. maybe the wrong options to reflash_ben
<wolfspraul>
when I get a new device, sometimes I spend the first day running into this kind of thing, like how to press the power button to reset it correctly, or so
<wpwrak>
or maybe it started from a bad cache, etc.
<wolfspraul>
then after that I use that device for years and find everything 'intuitive'
xiangfu joined #milkymist
<wpwrak>
yeah. you adjust your expectations ;-)
<stekern>
wpwrak: (soc/fn mismatch) possible. I tried a couple of combinations, fn built from HEAD and the stable version
<stekern>
my soc is built from HEAD
<stekern>
I'm not sure about my toolchain setup though, it's built from the 'scripts'. I understood that you've made a stackof patches that isn't included there?
<stekern>
what is the preferred way to build the toolchain?
lekernel_ joined #milkymist
xiangfu joined #milkymist
xiangfu joined #milkymist
xiangfu joined #milkymist
<wpwrak>
stekern: the patch stack is for rtems, yes
<wpwrak>
for the new soc, you need to build new rtems and then also new flickernoise from it
<wpwrak>
maybe also new milkymist.git (all master/head)
<wpwrak>
and i installed the pre-compiled SDK as baseline. i don't know if all the things find their way into the right places with just build_sdk.sh in milkymist.git
<wpwrak>
ah yes, and you need this in your environment: RTEMS_MAKEFILE_PATH=/opt/rtems-4.11/lm32-rtems4.11/milkymist
<stekern>
thanks
<stekern>
I found the patches from the mail in the ML already (I really need to go look there before asking here ;))
<stekern>
I think I have everything setup correctly now, but flickernoise is still not booting.
<stekern>
and it feels odd that the reflashing of stable doesn't work
<wpwrak>
lemme commit my cheat sheet ...
<stekern>
I'm rebuilding the soc with the "right" IP settings since I couldn't find a way to change them on the fly
<stekern>
let's see what happens when I try to boot from net
<wpwrak>
it figures out which partition you want to change from the file name
<stekern>
I've run the .batch files in soc and flickernoise through urjtag
<wpwrak>
never used them :)
<stekern>
the .batch seems to contain basically what you have in the end of m1nor
<wpwrak>
that sounds good. this part never changed. also the partitions were never rearranged, i think
<wpwrak>
oh, speaking of which
<wpwrak>
using git://github.com/milkymist/scripts.git, scripts/reflash_m1.sh, you want to do a reflash_m1.sh --lock-flash if you plan to use your M1 for non-development purposes
<wpwrak>
that way, it will protect the beginning of the NOR, and greatly reduce the risk of that pesky NOR curruption
<stekern>
ok, good to know
<stekern>
the nor corruption was only temporary, right?
<stekern>
I mean reflashing after it got corrupted would (likely) succeed
<wpwrak>
as in "a reflash will cure it", yes
<wpwrak>
yup
<wpwrak>
but it can knock out your standby bitstream, so M1 wouldn't even go into rescue. in fact, it almost always got the standby bitstream (about once in every 500 power cycles in my case)
<wpwrak>
urjtag still works, of course. so you can always recover if you're prepares
<wpwrak>
prepareD
<stekern>
ok, good
<lekernel_>
wpwrak: those include files not found are autocrap problems afaik
<lekernel_>
wpwrak: try removing all build-generated files
<wpwrak>
you mean "wipe the directory and start with a fresh checkout" ?
<lekernel_>
no, wipe the build directory (not the source directory)
<lekernel_>
also, be careful of the sometimes conflicting system_conf.h installed in /opt/rtems-4.11
<lekernel_>
remove it as well
<lekernel_>
note that the patches didn't change anything to the includes, so this is clearly a "rebuild" problem
<wpwrak>
hmm. i think i'll start with a different checkout. radical changes have that tendency of backfiring :)
<wpwrak>
yes, it seems that your search path is different or is interpreted in a different way
<wpwrak>
i just used the exactly relative paths that lead from the source to the include file, so unless cpp explicitly ignores the direct path, it ought to find them
mumptai joined #milkymist
<lekernel>
mh, you managed to turn off bitgen DRC? last time I tried -d, it didn't do a thing
<lekernel>
that was with ISE 13.2 though
<wpwrak>
it still complains endlessly :)
<lekernel>
most of the existing complaints that can be safely ignored
<lekernel>
that new one with I/O is a bit more worrying though
<lekernel>
afaik you always need a valid ISTANDARD and OSTANDARD on IOB... doesn't work when you also set some slew rate and drive strength?
<wpwrak>
maybe ... i didn't dare to give it too much encouragement to use this as an output
<lekernel>
and as I said... you can reroute only the net you modified just by removing its pips
<wpwrak>
also, if i do, at some point it will ask for a net to drive the "output"
<lekernel>
will be much faster
<lekernel>
hm, really? well, then
<lekernel>
I can send in another xilinx bugreport
<wpwrak>
(pips) i don't really trust that xdl tool :)
<wpwrak>
the test case for this one would be: xdl -ncd2xdl, then use the upper part of xdlfixes (that handles the commas), then xdl -xdl2ncd and it'll complain about all the LVCMOS33 inputs
<wpwrak>
you can probably make a simpler test case that doesn't even have commas that need fixing
<wpwrak>
i kinda wonder if the LVCMOS33 problems mean that something is weird with the way we declare our buffers ... or that xilinx have a very interesting regression test process for xdl
<lekernel>
wpwrak: how do you choose the I/O locations?
<wpwrak>
by net - i recycle the exp<N>
<wpwrak>
that way, i can just reuse the entire "inst" block of the pad and only need to do a few small edits
lekernel joined #milkymist
wolfspraul joined #milkymist
gbraad_ joined #milkymist
gbraad_ joined #milkymist
xiangfu joined #milkymist
mumptai joined #milkymist
mumptai joined #milkymist
<stekern>
ok, I solved the reflash_m1.sh problem at least
<stekern>
mostly (l)user fault...
<stekern>
there's no standby.fpg in updates/current
<stekern>
so standby image is just erased
<wolfspraul>
stekern: wait, maybe we can improve something
<wolfspraul>
can you explain that again?
<stekern>
well, probably you want all images in update/current
<wolfspraul>
I thought it sounded like some smaller trap you fell into, because the community is still small the tools sometimes work only in a narrow band of 'typical' usage
<wolfspraul>
at least no bigger problem, that's good
<stekern>
I ran: ./reflash_m1.sh --release current
<stekern>
it tries to fetch standby.fpg, but since it doesn't exist in updates/current a 0kb file is created and "flashed"
<wolfspraul>
ok
<wolfspraul>
got it
<wolfspraul>
that should be easy to improve for xiangfu
<wolfspraul>
thanks a lot for the feedback!
<stekern>
yep, np
<wolfspraul>
any feeling already on where m1 will take you, what plans you have?
<stekern>
I would have saved myself some trouble if I'd just would have looked in the directory it fetches the images into earlier ;)
<wolfspraul>
nah, the script must be more robust
<wolfspraul>
trust me it got *A LOT* better over the last year already, but I think all those first steps can be made a lot easier and more robust still
<wolfspraul>
with documentation, help, error handling, etc.
<stekern>
my plans are mostly to hack on it, it's a cool board with a cool soc
<wolfspraul>
building, reflashing, web update, jtag, debugging, more 'how to get started' intros
<wolfspraul>
great
<wolfspraul>
well you hang around a lot here already, so nothing much I can quickly tell you about I think
<wolfspraul>
you probably know more than me, I am very interested in what you believe the lowest hanging fruits are, where we should take Milkymist, etc.
<kristianpaul>
cool soc, indeed, very suitable for hacking
n0carri3r joined #milkymist
<n0carri3r>
morning all
<stekern>
to be honest, I don't know. As for the purpose of the product, I know nothing about VJing. I'm mostly attracted by the technology
<wolfspraul>
n0carri3r: morning
<wolfspraul>
stekern: that's perfect, when I got into the project I thought it's a quick way to have a free CPU
<wolfspraul>
:-)
<wolfspraul>
but I don't regret having learnt what I did since then, and the path is good and promising
<wolfspraul>
n0carri3r: I tried to send a message to Emely via youtube, not sure she got it I really hope so, it would be great to get access to a freely licensed high-res download version of the cheap dinosaurs video with your visuals...
<n0carri3r>
OK i'll send her a msg, too
<n0carri3r>
to doublecheck
<wolfspraul>
yeah no rush
<wolfspraul>
she seems to be on a really solid project documenting all this with good videos
<n0carri3r>
i'll do it now - before i forget :)
<n0carri3r>
yeah, thats her thing now it seems
<n0carri3r>
just going to shows and taping ALL of them
<n0carri3r>
people are really excited about it
<wolfspraul>
impressive
<wolfspraul>
so motivating to see good work like that
<wolfspraul>
me too
<n0carri3r>
ok i left her a msg
<n0carri3r>
trying to get finished my other work for today, so i have time to copy some of those patches i wrote
<n0carri3r>
well, i have the time now, but i will want to keep messing around with them if i hook up my M!
<n0carri3r>
M1
<n0carri3r>
but i'll be lurking here while i work, ttyl
<wpwrak>
stekern: (all images) you have my vote :)
<wolfspraul>
we should have an option in the gui that will upload a patch to pastebin or so
<wpwrak>
stekern: (images) i think the cache should also use checksums. otherwise, there's just more trouble waiting to happen there. i also ran into cache problems.
<stekern>
hmm, where are they cached?
<stekern>
or even; what is cached?
<wpwrak>
stekern: the checksums ? afaik, there are none :) what i mean is the cache under $HOME/.qi/
<wpwrak>
wolfspraul: i think we need a proper patch repository. think of flickr or, even better, ccmixter.
<n0carri3r>
wolf: emily says: "yeah, i'll get them the master files, gotta upload them to my server"
<wpwrak>
the repository should at least show some states of the patch (e.g., one or more screenshots). better yet, the patch in motion.
<wpwrak>
there are of course a few tricky issues to solve :)
<roh>
wpwrak: animated gif?
<roh>
*scnr*
<wpwrak>
roh: well ... better than flash :)
<roh>
'just' needs a patch renderer in sw *ducks*
<wolfspraul>
n0carri3r: wow perfect!
<wpwrak>
is here actually anything that works like animated gif ? (and doesn't make browsers go wild and launch weird "media players" and such)
<wpwrak>
(patch renderer) indeed. that's what i think we should aim for, at least conceptually.
<roh>
wpwrak: no. there was MNG which is like animated gif to gif, but with png, but i assume browser support is bust
<wpwrak>
my vision is like this: 1) a collection of Free (CC0, PD, WTF, CC-BY, CC-BY-SA) "infrastructure" content. audio tracks, video in, now also images. i.e., things to use in the patch to showcase it, without creating copyright issues.
<wpwrak>
i think "we" need to provide these items, because not everyone will be able and willing to find them on their own. they may not even fully understand the requirement and thus consider it a nuisance we arbitrarily impose. so better to make this as painless as possible.
<roh>
btw.. it seems our plastic-3d printer now works
<wpwrak>
2) a "make demo" mode in which an M1 session is recorded with one of these inputs plus a patch and the control inputs ("MIDI track")
<wpwrak>
(3d printer) can't be. or else you wouldn't be typing here but be over there, drooling :)
<roh>
wpwrak: 'its printing'
<roh>
thats like 'its compiling' ;)
<wpwrak>
(make demo) in fact, only the patch, the MIDI track, and the IDs of the multimedia files need to be recorded, since we already have the full multimedia files
<wpwrak>
3) upload all this information to share.milkymist.org, where it can then be rendered in various formats and included in the "gallery"
<wpwrak>
(printing) you'd still be drooling :)
mumptai joined #milkymist
<kristianpaul>
also a performance repository wichis the equivalent to a VJ theme i think
wolfspraul joined #milkymist
<wpwrak>
you mean videos of M1+VJ ? or live shows ?
<kristianpaul>
no no, there is a perfornamce file i think or soemthing
<kristianpaul>
wich remenber keybiding for patches
<wpwrak>
ah, the patch sequence and such, yes
<kristianpaul>
yes
<wpwrak>
yes, the MIDI/key/etc. bindings need to be connected to the patch, too. that's a separate issue :)
<kristianpaul>
:)
wolfspra1l joined #milkymist
mumptai joined #milkymist
<wpwrak>
lekernel: you were right. i got a fresh rtems to build even without the include fixes. interestingly, there's something in there (rtems) that breaks some parallel partial makes. oh well ....
wolfspraul joined #milkymist
<lekernel>
do you really want to fix autoconf scripts? :-)
<wpwrak>
no, not really :)
<wpwrak>
i think the experience of cleaning my teeth using a rectally inserted red-hot poker as a toothpick would be vastly preferable to messing with autocrap :)
<wpwrak>
oh. they *just* fixed chain.inl. nice :)
<lekernel>
they also fixed _RBTree_Container_of
<wpwrak>
whee ! that must have been a few seconds later then :)
<wpwrak>
do they already have an opinion on the elephant in the room, i.e., the queue corruption ?
<wpwrak>
does "running FN and hammering your MIDI controls and/or mouse for a while" qualify as "complicated set of conditions" ? :)
<wpwrak>
good resolutions for 1963 and 1964
<stekern>
yay, "homebuilt" flickernoise boots
<stekern>
the only step I missed (I think) from your cheat list wpwrak was the building rtems-yaffs2
<wpwrak>
not bad :)
sh4rm4 joined #milkymist
DJTachyon joined #milkymist
<stekern>
still something up with USB though, the terminal is spewing out "RX bitstuff error"
mumptai joined #milkymist
<wpwrak>
in the bios ?
<kristianpaul>
sounds liek rtems shell
<stekern>
yes, in the bios
kristianpaul joined #milkymist
kristianpaul joined #milkymist
<wpwrak>
hmm. what USB device(s) is/are connected ?
<wpwrak>
lekernel: supporting the LV3 will be the ideal exercise for maximizing the flexibility of MIDI control handling
<wpwrak>
i think i've figured out most of its features by now. quite amazing just how many different reactions to actions and overlays it has.
<wpwrak>
e.g., the rotary encoders have no less than 11 virtual groups, selected with the black buttons (8+2+1)
<wpwrak>
when you push the encoder, it acts as a toggle. with LED indication. and the LED state is remembered, so it changes when changing virtual groups.
<wpwrak>
you can also set the toggle/led via MIDI
<wpwrak>
and when you press Shift, the encoders act as another group (different control number) of encoders, and pushing them turns has a tact function (no toggle)
<wpwrak>
phew :)
<wpwrak>
everything but Shift sends something, so you can keep track of what's going on
<wpwrak>
(and possibly counteract if you don't like what the LV3 decides to do. e.g., the black buttons would be nice for image selection, but then you may not want them to mess with the encoder state)