Topic for #milkymist is now Radical Tech Coalition :: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
<wpwrak>
plan B would be to use midi-over-osc. that should also work with the nov 29 build
<wpwrak>
and that's the only sane way to use the lvl3 at the moment. likewise, it allows you to use multiple midi devices without running out of M1 usb ports
<wolfspraul>
yes but too lazy for that now, I should get the update soon
<wpwrak>
:)
<wolfspraul>
just checked rii a bit, seems in china ca. 20 USD
<wolfspraul>
retail. maybe we should kick out the silicone keyboard and include that instead?
<wolfspraul>
I will definitely buy some for myself and others, then we see. and you say this works well?
<wolfspraul>
the touchpad works well too?
<wpwrak>
yes, works well
<wolfspraul>
what is the weight?
<wpwrak>
it's small, so it's not excessively comfortable
<wolfspraul>
(if you have a scale, otherwise I trust the numbers I find on the web)
<wpwrak>
very light :)
<wolfspraul>
do you have a scale?
<wolfspraul>
the silicone keyboard is quite heavy, ca. 250g
<wolfspraul>
our retail box is squeezed tight at 2000g, we have like 10g left or so ;-)
<wpwrak>
95.4 g
<wolfspraul>
wow, less! good
<wolfspraul>
I will investigate that, sounds like replacing the silicone keyboard with something like that could be an option
<wpwrak>
it's about 15 x 6 cm. pocketable
<wolfspraul>
especially if we can find a cheap no-name but good quality source
<wpwrak>
limitations: 1) rechargeable battery, so it has limited life expectancy. 2) RF, so it may not be safe to use for performances. 3) pretty much all the M1's keyboard shortcuts aren't accessible. but IMNSHO that's more a result of a peculiar choice of shortcuts ;-)
<wolfspraul>
#3 is not a problem, just reminder
<wolfspraul>
#2, don't know
<wpwrak>
and, and 4) small. can get lost. you can "park" the usb dongle inside the keyboard, so at least it won't be a loose bit that gets lost even quicker
<wolfspraul>
I'm not worried about that right now
<wolfspraul>
biggest problem for me is price
<wolfspraul>
and the fact that there's a battery inside, creating customs problems sometimes
<wpwrak>
good features: 1) has keyboard and mouse. 2) does not waste desk space ;-) 3) keys have backlight
<wolfspraul>
(though only on paper, we have been advised to simply not talk about the battery in the remote control, for example)
<wpwrak>
;-))
<wolfspraul>
paper meets real life
<wpwrak>
i one ordered a few li-ion batteries from digi-key. something like five cr2032-sized thingies. the labels on the box looked as if it contained bomb parts.
<wpwrak>
s/one/once/
<wolfspraul>
can the battery inside the rii recharge? is there a way to use a usb cable directly?
<wpwrak>
the usb cable is only for recharging
<wolfspraul>
ah
<wolfspraul>
that's not very practical
<wolfspraul>
so if your battery runs out in an emergency, what do you do?
<wpwrak>
it runs quite a while without recharging. at the rate at which i use it, it lasts for weeks if not months
<wpwrak>
you plug it into usb power
<wolfspraul>
and then wait? or can you use it right away?
<wolfspraul>
can you plug it into the 2nd plug on m1?
<wpwrak>
not sure. it may need a few seconds. i don't think you have to wait long.
<wpwrak>
sure. or a laptop. whatever.
<wolfspraul>
ok but m1 also - it works?
<wpwrak>
i haven't tried, but there's no reason it wouldn't work. it's just power :)
<wolfspraul>
:-)
<wolfspraul>
so we can assume it works
<wolfspraul>
if we include something like that, we can remove the IR control
<wpwrak>
heh ;-)
<wolfspraul>
I don't want to remove IR itself, it may have use in the future
<wolfspraul>
I mean the sensor on m1
<wolfspraul>
but the remote can go, it's not very good anyway (no custom printing), and would require a lot of work to do better (just sourcing and details, for example no backlight right now etc)
<wpwrak>
if we reassign some of the keyboard shortcuts, the rii would make a more than suitable remote control, yes
<wolfspraul>
yes and we can focus
<wolfspraul>
the remote control is one of the things that causes me headaches
<wpwrak>
range is a bit limited. something like 2 m. but some may consider that a feature :)
<wolfspraul>
not practical/good (not that anybody would care :-))
<wolfspraul>
I don't like the tactile feedback of our remote control, and that there's no backlight
<wolfspraul>
I don't like that it doesn't have milkymist-specific printing, so the symbols are all random and wrong
<wolfspraul>
we are buying them from a strange reseller in taipei, it is difficult to find a good vendor because little innovation in that space
<wolfspraul>
that means it's even expensive, I think we paid 4 USD or even more for this thing
<wolfspraul>
maybe even 6
<wolfspraul>
so maybe we kick out remote + silicone keyboard, and add a rii remote instead
<wpwrak>
and you may even save money ;-)
<wolfspraul>
it's lighter, much more suitable to our use case
<wolfspraul>
unlikely, but cost should be 10-15 USD more
<wpwrak>
at some point, you could even think about having an internal usb port :)
<wolfspraul>
which may be worth it if I think about how much more fun and useful the product becomes
<wolfspraul>
you mean inside the case?
<wolfspraul>
let's do it in rc4 :-)
<wpwrak>
yes, inside
<wpwrak>
i already see rc4 follow the path of pcs ;-)
<wolfspraul>
so the infrared would still be there, but would need software support to really support 'any' or at least 'more' rc5 controls
<wolfspraul>
and no remote control is included
<wolfspraul>
but the rii kbd is
<wpwrak>
in the old days, they started with 2-4 usb ports. nowadays, we're probably at something like ten on a new pc. maybe more :)
<wolfspraul>
I like the idea
<wolfspraul>
because I think the protectiveness of the case is very important and valuable
<wpwrak>
yup
<wolfspraul>
so maybe we can think about that together with the expansion system spec
<wolfspraul>
because it's all about mechanical and reserving space
<wolfspraul>
I will seriously investigate the rii idea now
<wpwrak>
ideally, such an internal port would be located such that it's safe to place strong RF there. so one could use it for wlan or such as well
<wolfspraul>
can't the pad of the rii also be an x/y control?
<wpwrak>
not sure if mouse pads can send absolute coordinates
<wolfspraul>
ok but it's an idea
<wpwrak>
but it's a bit on the small side for that anyway
<wpwrak>
e.g., the kaossilator's pad is about 10x8 cm. and it feels like a good size. not too small. not too big.
<wpwrak>
the rii's pad is about 3.5 x 3.5 cm
<wpwrak>
enough for mousing around, but small
<wolfspraul>
yes, but I mean little things
<wolfspraul>
we could even *swipe* through patches!!!
<wolfspraul>
out of the box
<wolfspraul>
that makes us one of the big guys, clearly
<wpwrak>
we cuold do that ;-)
<wolfspraul>
every tech CEO nowadays explains the power of his company by swiping over whatever crap they produce
<wolfspraul>
then i can finally take m1 out of the box, hook it up, and *SWIPE* over that thingie to flip through patches
<wpwrak>
swipe and crap. sounds like very traditional technology ;-)
<wolfspraul>
-> big bucks will come in
<wolfspraul>
just kidding, but I am thinking about the consequences of includign the rii
<wpwrak>
i see that you've been working on your convince-the-investors skills ;-)
<wolfspraul>
and one would be that the little pad could be a starting point for people to play
<wolfspraul>
and yes, we could even swipe through patches :-)
<wpwrak>
in general, i don't think you want the pad to be able to do anything when in performance mode
<wolfspraul>
not even a swipe? come on!!! please!!!
<wpwrak>
even the touch-to-click that kicks you right back into the UI is rather annoying
<wolfspraul>
sure that's horrible
<wpwrak>
see also jon's experience with a regular mouse. it gets much worse with a pad
<wolfspraul>
but the pad could be a starting point for play, still. why not.
<wolfspraul>
if it's a seamless experience overall
<wolfspraul>
anyway, small detail
<wpwrak>
it would be a bit of a cryptic experience. more a hackaday type of thing :)
<wpwrak>
but yes, the great unified input event system i have i mind should support such things as well. also user-assigned keyboard shortcuts. e.g., to select patches. T for tornado, S for starpainter (pleiades), P for pac man
<wolfspraul>
wonderful
<wolfspraul>
just checked, I paid 4.18 USD for each of 90 remotes
<wolfspraul>
and that was partially out of frustration already because I couldn't get all the things I wanted with great tactile feedback, backlight, milkymist printing, etc. so I just gave up and included *something* that at least technically worked.
<wolfspraul>
going back to the remote and fixing it by killing it sounds like a fair revenge
<wpwrak>
how much was the rubber keyboard ?
<wolfspraul>
laughable cheap, I think 2.70 USD or so
<wolfspraul>
unbelievable if you cut one open and think about all the parts and work steps
<wpwrak>
amazing indeed
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
<GitHub9>
[scripts/master] update rtems cvs always have problem. disable it for now - Xiangfu Liu
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
cladamw_ [cladamw_!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
<wpwrak>
xiangfu: seems that rtems is on an extended vacation, eh ? also no commits in git
<xiangfu>
wpwrak, yes. the cvs have read one and people who working on git conversion is on vacation.
<xiangfu>
cvs have set as READ ONE
<wpwrak>
aah ! that makes sense then
<wpwrak>
so cvs is history now ? good :)
<xiangfu>
yes. cvs is history now.
<xiangfu>
wpwrak, Hi I would like jump to work on milkymist again. can you please give me some task. easy task :) thanks.
<xiangfu>
wpwrak, I would like the fix the combo keyboard mice problem. will try in next few days and give feedback.
<xiangfu>
wpwrak, last time I just read the document about HID. didn't try to write any code. :(
<wpwrak>
heh, be careful about wishing for more work :) i think wolfgang will put you formally in charge of release engineering in a few minutes ;-)
<wpwrak>
regarding HID, I was planning to do that report parsing myself. i have a big bag full of mice waiting for testing all that :)
<wpwrak>
but something completely different that would be useful is a visual audio level indicator. like those green-orange-red bars you have on a lot of devices
<wpwrak>
that could, for example be on the side of the sliders in the audio settings dialog
<wpwrak>
that way, one could finally have a clear idea of what's going on with those audio signals. right now, it's pretty mysterious. sometimes things work, sometimes not, and you can only guess what may be the trouble, because there's no direct indication.
<wpwrak>
would that something that could interest you ? it would be very useful to have
<xiangfu>
'audio indication' I will take a look of that. hope it not very hard. :D
mumptai [mumptai!~calle@brmn-4db77299.pool.mediaWays.net] has joined #milkymist
<xiangfu>
about release. since we have the daily build. most of the works is test. make sure there is no regression.
<xiangfu>
first I need scp a whole 'rtems' to fidelio. since the rtems upstream cvs not working.
<xiangfu>
and before the rtems git works. will not update rtems anymore. :)
<xiangfu>
wpwrak, what is the command that revert all local cvs changes? I think i have some change in my local rtems cvs.
<wpwrak>
(not update) there's nothing to update anyway :)
<xiangfu>
wpwrak, I would like to learn more about software develop. still have a loooooooooong way for me. sometimes I think I am good. but when I look at you or Sebastien's code I have to say must keep learning. :D
<wpwrak>
i think removing your file(s) and then updating should discard the local changes
<wpwrak>
cvs diff should tell you if there are changes
<xiangfu>
wpwrak, (rtems update) yes. in the build script it delete rtems and do a clean cvs checkout. :)
<xiangfu>
wpwrak, doing cvs diff now. that take very long time. :(
<wpwrak>
(a lot to learn) M1 is a pretty complex project :)
<GitHub155>
[flickernoise] wpwrak pushed 10 new commits to symtab: http://git.io/YUeQwA
<GitHub155>
[flickernoise/symtab] compiler: rename unique_{free,dump} to symtab_* - Werner Almesberger
<GitHub155>
[flickernoise/symtab] compiler: optionally warn if using a variable in the wrong section (WIP) - Werner Almesberger
<GitHub155>
[flickernoise/symtab] compiler: added per-symbol flags to symbol table - Werner Almesberger
<xiangfu>
wpwrak, I have a question about fpvm. how does it works? is it do float calculate on the video memory?
<xiangfu>
the rtems cvs have problem recently .
<xiangfu>
when do 'cvs update' or 'cvs checkout' it will give you a lot of 'cvs checkout: [06:51:20] waiting for cvspserver's lock in /usr1/CVS/rtems/testsuites/psxtests/psx16' and stop there.
<wpwrak>
fpvm just calculates on aset of registers. the results are then picked up by flickernoise. and some of the results go to the texture mapping engine, for the distortions.
<wpwrak>
fpvm doesn't touch pixel data
<xiangfu>
ok.
<xiangfu>
the texture mapping engine is VerlogHDL code. right?
<xiangfu>
who send the final result to video memory?
<wpwrak>
that's all in verilog. including the data paths to/from video memory
<xiangfu>
ok.
<xiangfu>
the new rtems git repo will be up this weekend. so I will setup and clean the daily build after this weekend. :)
<wpwrak>
let's hope they export the things we need again
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
<wolfspraul>
the Linux we have running on M1 today, does it support USB and USB hubs?
<wpwrak>
seems unlikely, considering that out interface is at a completely unexpected layer
<wpwrak>
s/out/our/
<wpwrak>
i.e., the navre hides USB from the lm32
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
r33p [r33p!~rep@bon31-2-89-85-157-97.dsl.sta.abo.bbox.fr] has joined #milkymist
<larsc>
wolfspraul: linux only supports usb keyboards
<wolfspraul>
ah but that's a start
<wolfspraul>
how hard would it be to make that more generic?
<larsc>
impossible
<larsc>
navre does part of the usb protocoll handling
<larsc>
so we have to write a special driver for each usb peripheral type we want to support
<wolfspraul>
hmm, ok. no fun if things just worked... :-)
elldekaa [elldekaa!~hyviquel@adm02.insa-rennes.fr] has joined #milkymist
elldekaa [elldekaa!~hyviquel@adm02.insa-rennes.fr] has joined #milkymist
elldekaa [elldekaa!~hyviquel@vpn2.enssat.univ-rennes1.fr] has joined #milkymist
lekernel [lekernel!~lekernel@g226059040.adsl.alicedsl.de] has joined #milkymist
<lekernel>
larsc: you just have to load a different firmware into the softusb core (this can be done by the linux driver)
Martoni [Martoni!~chatzilla@arc68-5-88-188-247-92.fbx.proxad.net] has joined #milkymist
elldekaa [elldekaa!~hyviquel@vpn2.enssat.univ-rennes1.fr] has joined #milkymist
cladamw [cladamw!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
<kristianpaul>
or use a bloated usb host core from opencores that claims linux support
* kristianpaul
hides
<stekern>
the linux driver for that is rather hideous though ;)
<kristianpaul>
ha
<kristianpaul>
hw? too bloated really?
<stekern>
To be honest, haven't looked more carefully at the rtl for it
<stekern>
I've written a driver for u-boot for it, works well enough to load a linux image from usb-stick with it at least
cladamwa [cladamwa!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
<larsc>
hm, is there a vhdl equivalent of the verilog unary logical operators?
<stekern>
afaik, no. you can do the equivalent with for loops, although it's a lot uglier than the verilog reduction operators
elldekaa [elldekaa!~hyviquel@adm02.insa-rennes.fr] has joined #milkymist
wolfspra1l [wolfspra1l!~wolfsprau@p5B0ABC34.dip.t-dialin.net] has joined #milkymist
elldekaa [elldekaa!~hyviquel@vpn2.enssat.univ-rennes1.fr] has joined #milkymist
cocoadaemon [cocoadaemon!~cocoadaem@2a01:e35:8a99:e90:20d:93ff:fe3b:868c] has joined #milkymist
cocoadaemon [cocoadaemon!~cocoadaem@2a01:e35:8a99:e90:20d:93ff:fe3b:868c] has quit [#milkymist]
azonenberg [azonenberg!~azonenber@cpe-67-246-33-188.nycap.res.rr.com] has joined #milkymist
<wpwrak>
wolfspra1l: how's the icreativ front ? :)
<wpwrak>
looking at the original "A Matter Of Taste" patch ... i see a lot of per_frame_N and per_pixel_N. is such prefixes ending in a number something we should support ?
<lekernel>
wpwrak: "support" meaning "ignoring those numbers", yes
<lekernel>
(as my original compiler did)
<wpwrak>
okay. i missed that. is per_frame(_[0-9]+)? permissive enough ? or could there be other stuff ?
<wpwrak>
and is there an sane source for the original of "Unchained - A Matter Of Taste (Remix).fnp" ? all i see are dubious file hosters with no hint what version that file is
sh[4]rm4 [sh[4]rm4!~sh4rm@gateway/tor-sasl/sh4rm4] has joined #milkymist
<wolfspra1l>
wpwrak: waiting for update (and busy with other tasks right now)
<wpwrak>
heh. thought you'd be more eager to explore the dungeons of milkymist ;-)
<wpwrak>
btw, i warned xiangfu that you'll probably ask him to take over the releases (assuming coordination with sebastien. but i guess he'll be happy to be rid of that task)
<wolfspra1l>
we had that plan for a while but for some reason it's not happening
<wolfspra1l>
have to find out why
<wolfspra1l>
I am eager, but I have too many little things right now and the update will surely be there soon.
<wpwrak>
(releases) from the outside it did look as if it had happened :)
<wpwrak>
what's that update ? are you rebuilding lots of things ? or waiting for someone to rebuild things ? or just downloading over a 1200 bps modem ? :)
<wolfspra1l>
is there anything new if I press the update button?
<wolfspra1l>
I think I have the current latest release
<wolfspra1l>
I could reflash something from qi-hardware.com, I think (the buildhost)
<wpwrak>
i'd just download the files and m1nor them
<wpwrak>
thinking of it, i should probably set the write protection in m1nor. i leave it off deliberately for my own uses, but my use case is a bit twisted
elldekaa [elldekaa!~hyviquel@vpn2.enssat.univ-rennes1.fr] has joined #milkymist
<wpwrak>
very interesting. the lockflash seems to mess up JTAG such that only power-cycling brings the M1 back to life :)
<wpwrak>
perhaps there's a wait-for-busy missing somewhere ...
mumptai [mumptai!~calle@brmn-4db77299.pool.mediaWays.net] has joined #milkymist
<wpwrak>
hmm. not jtag seems to be borked. just that "supervisor" thingy in the fpga
<wpwrak>
so ... about the idea of having internal usb ...
<wpwrak>
wolfspra1l: i'd say two ports would be better than one. we may have more "permanent" things than just an RF keyboard
<wpwrak>
e.g., WLAN or maybe a USB flash stick
<wolfspra1l>
I think the 100mil 4*1 male headers are sort of standardized, no?
<wolfspra1l>
I remember from many years ago that there were different pin assignments, but then they converged
<wpwrak>
yes, 4x1 or 5x1 are pretty common. the most common is the 5x2-1 you have on mainboards
<wolfspra1l>
ah well
<wolfspra1l>
4 or 5 :-)
<wolfspra1l>
the link you posted yesterday pointed to a 4x1 one
<wolfspra1l>
and that was definitely meant to go to a PC mainboard
<wpwrak>
4x1 is the minimum you need. some may add one more pin for keying and such
<wpwrak>
lekernel: yes, that one
<wpwrak>
lekernel: pretty funny. when i lockflash immediately after writing, then the pld reconfigure (in m1nor) works, but the pld load (in make boot) has no effect. no matter how often i try
<wpwrak>
lekernel: when i put something between the flashing and the lockflash, things change. now i get a complaint that the flash type is unknown (and then it doesn't do the locking)
<wpwrak>
more trial and error needed ...
<wpwrak>
ah. 4x2. even easier then
<wpwrak>
you should also be able to use a 4x2 or 5x2 header with a 4x1 cable
<wpwrak>
or two such cables
<wpwrak>
maybe behind the outermost dmx connector would be a good place. then a dongle would be above the NOR. with a little luck, it won't EMI-upset it too much. if not, we already know the NOR debugging drill ;-)
<wpwrak>
not sure how much trouble it could cause for video in. but i guess there's no way to tell without trying
<wpwrak>
oh, and i wonder if we really need transceivers there
<wolfspra1l>
we can leave looking for space to the layout people
<wolfspra1l>
at least initially
<wolfspra1l>
such a header would continue with a cable anyway
<wpwrak>
(transceiver) it's not as if there was much opportunity for the signals to get distorted
<wolfspra1l>
you mean no transceiver at all?
<wpwrak>
how would you attach the dongle ?
<wpwrak>
yeah, just straight to the fpga. maybe we could even use the differential driver there.
<wolfspra1l>
can we try that first by removing/shorting the transceivers we have now?
<wpwrak>
lekernel: or is USB-straight-to-the-FPGA something xilinx strongly discourage for some reason ?
<wpwrak>
we can probably do better. hook the thing up to J21 :)
<wolfspra1l>
you mean just get one of those cables, connect to J21 and get it to work?
<wpwrak>
yeah. it's not trivial, though. the whole signal-level interface changes (apart from using different pins)
<wpwrak>
best with a little adapter so that 5 V and GND are at the right places.
<wpwrak>
i have a 4 x USB slot bracket with two 5x2-1 connectors. more than enough for some serious USB extravaganza ;-)
<lekernel>
removing the transceivers works, but it violates USB specs wrt rise/fall times and removes one layer of protection against electrically rogue devices
<wpwrak>
so not great but a possibility
<lekernel>
meh, not really
<lekernel>
a short with the 5V pin would easily damage the fpga
<lekernel>
unless you add zeners etc.
<lekernel>
then they add capacitance
<wpwrak>
the lockflash lockup is a tough cookie. a detectflash before it still makes things go wrong. yet another detectflash after it makes it work. let's see if i can reduce that madness a little
<wpwrak>
i think you want zeners in any case. ESD is everywhere.
<lekernel>
protecting against ESD is different from protecting against a permanent 5V short
<wpwrak>
true, yes
<wpwrak>
ah yes, transceiver is 5 V-proof
<wpwrak>
ah well, 2 USD more :)
<wpwrak>
m1nor updated. it's not pretty, but it seems to work.
elldekaa [elldekaa!~hyviquel@adm02.insa-rennes.fr] has joined #milkymist
<GitHub32>
[milkymist/symtab] libfpvm: make op_not a regular operator and implement it in all cases - Werner Almesberger
<GitHub54>
[flickernoise] wpwrak pushed 4 new commits to symtab: http://git.io/CNysDA
<GitHub54>
[flickernoise/symtab] ptest.c: restored dump_regs, using new forall_syms - Werner Almesberger
<GitHub54>
[flickernoise/symtab] compiler: remove "virtual ops" concept and use op_not from libfpvm - Werner Almesberger
<GitHub54>
[flickernoise/symtab] compiler: also support equation numbers after per_vertex/per_pixel - Werner Almesberger
<wpwrak>
lekernel: i've rearranged the handling of names a little. the most interesting spots would be libfpvm's headers (fpvvm.h and ast.h) and all the things i could then kick out of compiler.c
<wpwrak>
lekernel: i.e., the translation from name to index has not become an access to a field in the symbol table entry, with symbol table entries replacing pointers to names
<wpwrak>
lekernel: the symbol table has a "struct sym" for flickernoise and inside a struct fpvm_sym for libfpvm. the latter only contains the name so far but when i get to moving register allocation, it'll grow too
<wpwrak>
lekernel: for now, all this is in branches symtab because i didn't know if my ideas would work out in the end. but it seems they finally did :)
<wpwrak>
ah, and the new fun features are warning options on ptest (warnings aren't integrated into flickernoise yet. maybe i'll keep things simple and just make them errors)
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
<wpwrak>
the warnings so far are: -Wsection issues a warning when accessing a variable that's associated with a specific section in a different section. e.g., trying to use wave_x in a per-vertex equation
<wpwrak>
and -Wundefined warns if using a variable that's not defined. there are two variants: old-style, where the check is done at the end of parsing. so things like foo = foo+1 are accepted
<wpwrak>
and new-style, where the check is done immediately when accessing the variable. in the case of things like foo = foo+1 this means that foo has to be explicitly initialized. for this purpose, i allow assignments of the form foo = 0 in the initial/global section. the value must be zero for now.
Artyom [Artyom!~chatzilla@84.23.62.51] has joined #milkymist
<wolfspra1l>
ahh danny't mail is so great!
<wolfspra1l>
I couldn't agree more with him, those are exactly 100% the kinds of things we need to work on to make m1 a bigger commercial success
<wolfspra1l>
and we are, to the best of our abilities, so all cool!
<wolfspra1l>
he already bought a total of 6 m1 btw, just for the record
<wolfspra1l>
oh, and I think an rc2 as well, which he generously donated back to me
<wolfspra1l>
so make that 7
<wpwrak>
is he a reseller ? or does he have other plans ?
<wpwrak>
and yes, his experience sounds very familiar ;-)
<wolfspra1l>
danny is a hard-core free software guy, ex-fsf, involved in lots of free-whatever related things
<wolfspra1l>
he is reselling some, campaigning, donating, renting, using, etc.
<wolfspra1l>
he sells the rms lemote subnotebook in the US
<wpwrak>
kewl :)
<wpwrak>
rms has a laptop ? wow
<wpwrak>
(i mean design ownership, real or spiritual)
<wolfspra1l>
I'm a little worried about his mic and cam feedback
<wolfspra1l>
hardware issue?
<wolfspra1l>
probably not, but the way it's written there makes me worry
<wolfspra1l>
sure we have no level detection afaik
<wolfspra1l>
with usb-midi going a very good way, that could soon become the #1 wished product feature
<wpwrak>
mic and camera suck for me too. mic also seems variable. sometimes it's okay, occasionally deaf
<wolfspra1l>
yes
<wolfspra1l>
no doubt about that, but is it a hardware issue?
<wpwrak>
camera is okayish with my canon sd880 if i have a lot of light
<wolfspra1l>
right now I hope/think that it's not, but we only know for sure once we have them constantly working better out of the box
<wpwrak>
i.e., i take my pretty bright lab lamp and shine it directly in the face of people :)
<wpwrak>
may be bad settings
<wolfspra1l>
I think we shuold start with auto-sensitivity for the mic/line-in
<wolfspra1l>
before cam
<wpwrak>
naw, midi/IR/kbd control :)
<wolfspra1l>
oh sure, I mean after those
<wolfspra1l>
the audio and cam sensitivity are a problem
<wolfspra1l>
annoying. people expect this to be 'auto'
<wpwrak>
xianfgu asked me today if there's anything he could work on on the software. i suggested graphical level indicators for the audio dialog
<wolfspra1l>
I saw it
<kristianpaul>
my canon camera works nice too :)
<kristianpaul>
but the others wolfgang tested before no that bad, well cmos sucks..
<wpwrak>
"auto" may be tricky. you'll see once you have midi working. some patches have interesting thresholds that need to be met quite precisely
<kristianpaul>
but mic i havent noticed issues, actually it was really nice how some patches react to sound you really can see it
<kristianpaul>
but the mid treb and forgot the other variable indeed are not enougt..
<wolfspra1l>
oh I'm sure it is very difficult to make this work 'well' in the sense that the user is still in control, but the software still 'snaps' sensitivity level to where the action is
<kristianpaul>
audio people laught on me when i told that in comunlab... :(
<wpwrak>
and if you turn the volume up and down to match the unknown threshold the patch expects (they're all over the place), then you can see even a lot more ;-)
<wolfspra1l>
it needs time and steady polishing
<kristianpaul>
mixer ! no indicators ;)
<wpwrak>
yeah, no indicators. we keep on coming back to that. this seems to be the day for it, 3rd mention ;-)
<wolfspra1l>
kristianpaul: hey, of course you want to see patches react to mic :-)
<kristianpaul>
and did
<kristianpaul>
wonder what/wich one went wrong to daniel
<wolfspra1l>
but if you go through patches and play a little, you get the feeling that it could be so much better still (in a good way, it could go from good to great to unbelievably good)
<wolfspra1l>
it depends on patch and ambient sound level, I think
<wpwrak>
try tornado rain dance and play with midi4. it's very instructive :)
<wolfspra1l>
I think in many corners of the usage experience, there is room for the kind of improvement like werner showed once in his midi before-after video
<wolfspra1l>
that's a guess of course, my feeling that it *could* be, with more work
togi [togi!~yur@c83-250-142-73.bredband.comhem.se] has joined #milkymist
<wpwrak>
kristianpaul: oh, and another one to play with (this time without midi): the inner working of my new computer. just use the mic. then let something hard touch the table. all of a sudden you have starts flaring up everywhere
lekernel_ [lekernel_!~lekernel@f052069021.adsl.alicedsl.de] has joined #milkymist
<wpwrak>
oh, that was midi messages being lost
<wolfspra1l>
(I know this was caused by softwaer bugs, but my point is that I feel we have room for that dramatic kind of usage/quality improvement in many areas, as seen from a normal user like Danny)
<wpwrak>
oh, we certainly do
<wolfspra1l>
in 'before', it already *works*
<wolfspra1l>
and if you don't know how it could be, you might be happy
<wpwrak>
yes, indeed :)
<wolfspra1l>
but in case you settled for that, big mistake, check out what it looked like in 'after'
<wolfspra1l>
:-)
<wpwrak>
that's perhaps the biggest risk with such bugs. since people have no concrete expectations of how a milkymist shuold behave, they can't tell bug from design limitation
<wolfspra1l>
sure, but after working for 2 years with Milkymist, I know we are far from design limitations almost everywhere
<wolfspra1l>
so most/all of the stuff danny mentions can be improved a lot
<wolfspra1l>
him (or others) may not know, unless we specifically say so
<kristianpaul>
wolfspra1l: u havent play with all patches, tooo mnya for me :)
<kristianpaul>
also some of then boring (to me) to even deserver be tested ;)
<wolfspra1l>
yes but one reason they may be boring is precisely because their qualities are hidden
<wolfspra1l>
in many ways
<wolfspra1l>
it's an endless list of things to improve, so we are best just starting with what creates the most immediate improvement, one by one
<wpwrak>
let's talk about those hidden qualities when you have midi working :)
<wolfspra1l>
you think midi will uncover some of them, or you think I am mistaken? :-)
<wpwrak>
it will uncover them. at lest in patches that are midi-ready
<wpwrak>
well, i should use the singular form here :)
<GitHub94>
[flickernoise] wpwrak pushed 2 new commits to symtab: http://git.io/3-4B7A
<GitHub94>
[flickernoise/symtab] compiler: off-by-one error in forall_syms - Werner Almesberger
<GitHub94>
[flickernoise/symtab] added FN variable "frame" - Werner Almesberger
<wpwrak>
the inner workings of my new computer are now a bit less sedate
<wpwrak>
but i think it could benefit from manual speed control
mumptai [mumptai!~calle@brmn-4db77299.pool.mediaWays.net] has joined #milkymist
r33p [r33p!~rep@bon31-2-89-85-157-97.dsl.sta.abo.bbox.fr] has joined #milkymist
frdminc [frdminc!47c0a200@gateway/web/freenode/ip.71.192.162.0] has joined #milkymist
<frdminc>
Anyone around who could help me / point me to doc on how to get a DMX light working with M1/Flickernoise?
<wpwrak>
frdminc: xiangfu would be your DMX expert. he's in china, so it's around 7 am for him. may show up in a couple of hours.
<frdminc>
hmm dip switch on back with on: 1 (1), 4 (8), 10 (ON/DMX) - so guessing the start address is 9 - should get friend who donated these to get me model / data sheet...
<frdminc>
Wow friend got back to me quickly:
<frdminc>
They are addressable via the dip switches on the back... the least-significant 8 bits set the start address. One of them will be channels 1-4, the next 5-8, the next 9-12. I forget the channel order, but the 4 channels are R, G, B, and brightness/strobe. The brightness/strobe channel does fading from 0-127, strobe from 128-250 or so, and full-on at 255. I would start by setting all channels to 255 and then play around to find o
<frdminc>
Now I just need to figure out what exactly all that means :)