<wpwrak>
yeah. and a bit of crud removal is coming soonish :) (the whole cvar business i had added. silly over-engineering)
<lekernel>
n0carri3r: wow, you made that with the M1?
<lekernel>
"some SRSLY FLY vizzzz for @Nullsleep by Cosmic Morning "
<lekernel>
that one?
<lekernel>
wpwrak: I guess you're going to remove the midiX variables too?
<wpwrak>
pity that the exploding house is a video feed
<wpwrak>
lekernel: i very much looking forward to their killing :-) do you see any need to keeping them around for compatibility ? i don't thing there are a lot of people using them
<wpwrak>
s/thing/think/
<lekernel>
wpwrak: yeah, just remove them
<lekernel>
it's easy to copy and paste "midiX = ..." in any affected patch, anyway :)
<n0carri3r>
lekernel: yes, that top video
<n0carri3r>
will the M1 ever support animated GIFs?
<n0carri3r>
would be great - then the exploding house could be on the M1, too :)
<lekernel>
it can be done :)
<wpwrak>
maybe just an array of images ?
<n0carri3r>
really? that would AMAZING :)
<lekernel>
wpwrak: yeah :)
<wpwrak>
i have such a thing planned. now that the compiler is more or less under control, it won't be too hard to implement it. (the array of images)
<lekernel>
which is read automatically when a GIF image is loaded
<wpwrak>
do we have a GIF reader yet ?
<lekernel>
no, but we probably can just compile some linux library
<n0carri3r>
that would be great
<wpwrak>
okay, ffs ;-) in any case, you can just do individual frames.
<lekernel>
there's MNG too (which can be read with libpng) but it's lesser known than GIF
<wpwrak>
(copy & paste midiX) yes, unless you rely on the MIDI settings dialog to switch between different controllers or controller configuration. but then, i realize that i may be the only one doing that on a regular basis ;-)
<lekernel>
n0carri3r: your video is great! and with Nullsleep, wow :)
<n0carri3r>
thanks! we're good friends - and roommates :)
<wpwrak>
but i can fix that too by introducing another layer of abstraction. for now, i'll just cram everything into the patch, so it's easy to experiment with things.
<n0carri3r>
the moire patterns in that video are the M1, too - using two PNG
<n0carri3r>
with transparency and sine based movements
<lekernel>
n0carri3r: which USB-MIDI controllers do you have?
<n0carri3r>
and the "N" logo appears over top, because i found a way to jam multiple keys on the keyboards to "mix" patches - then let go of one key to allow one patch to take over
<lekernel>
and plan to use with M1?
<lekernel>
yeah, I added that "patch jam" feature as a little toy in the latest software release :)
<lekernel>
nice to see it used :)
<lekernel>
anyway, next sw should also allow you to have more pictures than 2 per patch
<n0carri3r>
its very cheap and i think many would purchase it to use with the M1
<n0carri3r>
has dials, sliders, and buttons on it
<n0carri3r>
oh, it seems there is a newer one, too: Korg nanoKONTROL2
<n0carri3r>
but i have the previous one. i'm sure they are very similar
<wpwrak>
the iCon i-creativ can also be an interesting choice
<wpwrak>
still inexpensive but feels a little less cheap than the nanoKONTROL2. there's a solid chunk of metal in there, making it heavy.
<wpwrak>
you can switch it between various types of controls, X/Y pad, faders, etc.
<wpwrak>
now to the achilles heel: they imho stupidly and unnecessarily limited the resolution of the pad to 16x8
<wpwrak>
so in X/Y mode, you only have 16 horizontal values, 8 vertical ones. if you use faders (except the analog one), then they also have only 8 values.
<wpwrak>
this limits what it can do. but it's still very versatile.
<n0carri3r>
yeah
<n0carri3r>
whatever gets supported, i will buy it right away :)
<lekernel>
afaik the nanoKONTROL2 is working (I remember wpwrak doing some tests with it). we didn't try the 1st version.
<wpwrak>
oh, pretty much anything usb-midi ought to work now :)
<wpwrak>
yes, i have a nanoKONTROL2. works fine. just feels incredibly cheap ..
<n0carri3r>
oh, really? USB-MIDI is supported in the current software?
<wpwrak>
aye :)
<n0carri3r>
wow! okay, i must finish my class prep for now, or i will spend my entire day playing around!
<wpwrak>
;-))
<lekernel>
it's just that we haven't sent it through the web updates yet
<wpwrak>
now we need more USB ports to be able to connect a lot of devices :)
<lekernel>
but we will :)
<n0carri3r>
ah! so its not on the web updates, yet? ok!
<lekernel>
no, it's only in the source code on github atm :)
<wpwrak>
for now, i still use my PC as "midi mixer": connect all the devices to it, the then send all the traffic via OSC
<n0carri3r>
i like the portability of the M1 for a live show with no laptop, though :)
<wpwrak>
as long as you don't run out of USB ports, you're fine :)
<n0carri3r>
i usually disconnect the mouse as soon as my "performance" is running, to avoid problems
<n0carri3r>
and just use the keyboard, for now
<wpwrak>
we're evaluating one of these little RF keyboard with integrated touch pad to replace the rubber keyboard in the future
<wpwrak>
that would need one port less. plus, you can turn it off when not in use.
<wpwrak>
and shipping weight goes down ;-)
<n0carri3r>
:)
<lekernel>
n0carri3r: would you have an higher-resolution version of that video?
<n0carri3r>
not at the moment, but my friend emily shot the entire set, along with a few other people
<n0carri3r>
when the videos surface, i'll let you know
<n0carri3r>
ok, i really wanna try that USB-MIDI. is it pretty easy to update the software manually from git?
<n0carri3r>
or will it be available soon via update?
<lekernel>
are you running Linux?
<n0carri3r>
OSX
<lekernel>
hmm ... in fact, we do have OSX instructions :)
<Fallenou>
hehe thanks, looks horrible to debug too
<GitHub71>
[flickernoise] wpwrak pushed 2 new commits to direct-midi: http://git.io/98PJ8A
<GitHub71>
[flickernoise/direct-midi] stimuli: added processor for acceleration with an unbounded range - Werner Almesberger
<GitHub71>
[flickernoise/direct-midi] stimuli: remember and update base pointer for stim_redirect - Werner Almesberger
methril|work [methril|work!~methril@188.141.121.132] has joined #milkymist
<lekernel>
Fallenou: I'd suggest you simulate it... it works with xilinx isim
<lekernel>
what do you think of using normal videos instead of GIF? I already got FFMPEG compiled...
<lekernel>
of course I don't expect realtime decoding from the LM32
<lekernel>
but pre-decoding small 1s-2s clips during patch compilation seems possible
<wpwrak>
hmm, with all the downconverting etc. you have to do on the video first, it may not be excessively useful
<wpwrak>
but then, it looks good on the feature list ;-)
<lekernel>
'all the downconverting'?
<lekernel>
you'd typically have to cut it already, even simply for aesthetic purposes... so resizing it at the same time doesn't sound like a big constraints
<Fallenou>
you can provide scripts to change size using gstreamer or ffmpeg so that the user can do it easily without being a pro of video editing
<Fallenou>
lekernel: oh simulating the whole lm32 cpu ? i didn't know it was possible
<wpwrak>
what i mean that you'll already edit it heavily, so rendering the result to images would't make much of a difference
<GitHub101>
[flickernoise] wpwrak pushed 4 new commits to direct-midi: http://git.io/jO2kjA
<GitHub101>
[flickernoise/direct-midi] compiler: fix NULL pointer bug when running patches that don't use direct MIDI - Werner Almesberger
<GitHub101>
[flickernoise/direct-midi] stimuli.c: ptrdiff_t is defined in stddef.h, not sys/types.h - Werner Almesberger
<GitHub101>
[flickernoise/direct-midi] compiler: don't include \n in "cannot add stimulus ..." message - Werner Almesberger
<Fallenou>
lekernel: do you have a link that gives a few intel about how to simulate lm32 with isim ?
<Fallenou>
if not I will start with reading isim doc :)
<lekernel>
Fallenou: you have to connect the buses to some simulated memories, with code in the instruction one
<lekernel>
then the isim command is confusingly named "fuse" and it compiles the verilog code into an executable binary
<wpwrak>
lekernel: are you working on adding movie support ? if yes, maybe i should merge some of my stuff into master, so we don't get a huge merge conflict later
<lekernel>
wpwrak: I can add it into libpixbuf and test it a bit, then you can make use of it?
<Fallenou>
lekernel: simulating wishbone accesses, I hope it won't take too much time to do
<wpwrak>
sounds good. i still need to to the multi-image support anyway
<lekernel>
we can simply treat the movie as one pixmap with multiple frames in it
<lekernel>
and the pixmap object has a new 'frame count' field
<wpwrak>
that should actually be easy now ... hmm ... but how do deal with the unfinished pile MIDI stuff ... ?
<lekernel>
what 'unfinished pile MIDI stuff' ?
<Fallenou>
I guess I can find already done "wishbone blockram slave"
<wpwrak>
my direct-midi branch
<Fallenou>
in order to plug to data and instruction wishbone path
<lekernel>
Fallenou: you can try the new migen stuff to build wishbone block rams :p
<wpwrak>
it's actually not that bad ... less than 1000 lines
<lekernel>
wpwrak: and what's the problem with it?
<Fallenou>
lekernel: I am planning on learning migen, but not now :p
<wpwrak>
the problem is that, if adding multi-image support off the master branch, i'll conflict with direct-midi. and i dislike merge conflicts ...
<lekernel>
wpwrak: continue with direct-midi... and we connect it to the movie-enabled libpixmap later
<lekernel>
after direct-midi has been merged into master
<lekernel>
I guess there will be no merge conflicts in libpixmap, right?
<larsc>
lekernel: does this look ok, for the splitter control fragment? http://pastebin.com/bw16qDUe it is basically the same as for the combinator, just with a extra buffer which saves whether a output token has been acked since the last input token
<wpwrak>
alight, let's do multi-image after direct-midi then. no, there shouldn't be any conflicts. i just made changes in renderer/ and compiker.
<wpwrak>
well, there will be a clash in src/Makefile, but that's kinda unavoidable
<wpwrak>
(and usually simple to solve)
<lekernel>
larsc: n = len(self.endpoints) will count both the sources (which you want) and the sinks (which I think you don't)
<lekernel>
n = len(self.endpoints)-1 ?
<larsc>
yes
<larsc>
i guess
<lekernel>
acked = Signal(BV(n), name="acked") <= the name parameter will automatically be set to "acked" (thanks to the bytecode hack), no need to duplicate it manually
<larsc>
is the bytecode hack already commited?
<lekernel>
yes
<larsc>
cause it didn't work here
<lekernel>
are you using cpython?
<larsc>
i guess
<larsc>
the python form python.org
<larsc>
3.1 though
<lekernel>
$ python3 --version
<lekernel>
Python 3.2.1
<larsc>
it seems to work for some of the signal names, but not in this specific case
<lekernel>
ah
<lekernel>
you're only declaring one signal in this frame, so there are no conflicts... maybe it simply omits it during the final naming phase
<lekernel>
what name do you get?
<larsc>
the opcode it gets during the name lookup are STORE_NAME, STORE_DEREF
<larsc>
opcodes
<lekernel>
hmm maybe we need to handle STORE_DEREF too
<larsc>
yes
<Fallenou>
OK let's install migen then
<lekernel>
larsc: other than these two details, it looks good :)
<lekernel>
should I commit it?
<Fallenou>
let's first install python 3.2 :/
<lekernel>
Fallenou: MMU, Migen... you'll soon become the pro of experimental milkymist code :-)
<lekernel>
larsc: ah, no, you must also deassert the source stb after it has acked it
<lekernel>
otherwise you'll get duplicate tokens
<larsc>
right
<Fallenou>
lekernel: ahah yep I hope =)
<larsc>
hm, ok, fixed the auto namer
<Fallenou>
lekernel: that's impressive, I just generated the build/soc.v using migen
<Fallenou>
very impressive what it's already capable of :)
<larsc>
is there a way to get the bv of an expression?
<larsc>
i guess not, unless the expression is just a signal