#milkymist IRC log for Wednesday, 2012-02-29

wolfspraulcladamw: good morning!01:30
wolfspraulso - how's R4 going?01:30
cladamwwolfspraul, good morning!01:33
cladamw1. will keep only one middle button by using state machine for the button behaviour proposed by Werner. this just to remove two buttons..01:34
wolfspraulswitch to 10*2 header01:35
cladamw2. (J21/J22 connector size) wait a bit, seems only kristianpaul replied. ;-)01:35
cladamwbut draft already edited with 10*2 female headers, no big sourcing issue.01:36
wolfsprauleverything else settled?01:38
wolfspraulhow about the ddc5v current limiting now?01:38
wolfspraulthe last mail was from sebastien who said he liked the micrel switch but felt the en & fault lines were excessive01:38
wolfspraulI think, lemme re-read01:38
cladamw3. (01:39
cladamwDVI-I DDC5V) from S├ębastien's last thread, he didn't against using current limit chip but but without connecting extra signals to the FPGA. Add test points at best.01:39
wolfspraulor nothing at all, and connect to 5V directly01:40
wolfspraulI even prefer that, but it's not a technical reason, just economical and gut feeling.01:40
wolfspraulso what do we do? micrel ic + test points?01:41
cladamw(10*2 header) if you'd like to directly go for werner's idea, then i go for it now. i.e. R4 will break compatibility on J21 for its ancestors.01:44
wolfspraulI think we already broke it several times01:45
wolfspraulfirst going from male to female, adding a second connector, now another row? :-)01:45
wolfspraulno problem I think01:45
cladamwwolfspraul, okay, then done on 10*2. ;-)01:45
wolfspraulit is still possible to hookup old expansion boards on R4, just (even more) hacky01:46
wolfspraulsourcing improvements are very important though, I really want to build the entire m1 out of easy-to-source parts01:46
wolfspraulthat's an important objective01:47
cladamwwpwrak, to last DDC5V replied thread by Sebastien, how's your thinking now? micrel ic + test points?01:47
wolfsprauldon't ask him01:47
cladamwha...he'll mad? ;-) if yes, sorry. :)01:47
wolfsprauloh no, all relaxed01:48
wolfspraultest points is a good compromise I think01:48
wolfspraulif werner totally cannot live with that, he will speak up ;-)01:48
cladamwokay. so I'll edit them today.01:49
wolfspraulso we go into routing soon?01:49
cladamwnot yet...so we finised all dmx/video insertion/removal? i don't think so. ;-)01:50
cladamwone another thing is how we placement those 'reserved' matrix-led ? i think wener should have his good idea. ;-)01:51
wpwrakwolfspraul: (J21) there are two variants: one has ...-3V3-5V-GND, the other has ...-3V3-GND-5V. M1rc3 has ...-3V3-5V. so we still need to pick variant a or variant b :)01:51
wpwrak(routing) i think we should first call for a public schematics review01:52
cladamwwpwrak, we still have 8 reserved matrix-led, do you remember them ?01:53
wpwrak(reserved leds) uh, as far as i'm concerned, whichever way you want :) the leds are bright, so you don't need to squeeze the last photon out of them anyway. and we don't have a problem with current either. so anything will work.01:53
cladamwsee Misc.SchDoc. ;-) what you mean is let house to place them as convenience as they want ?01:55
kristianpaulcladamw: oh, Hi01:56
cladamwI'd rather place those 8 to be together in top side and/or close to board edge or somewhere.01:56
cladamwkristianpaul, thanks for your inputs. ;-)01:56
kristianpaulwell all is okay, what you already had decided is is good, so any mechanical situation well, you know more than me01:57
kristianpaulbtw i dint understood at the end why moved to female01:57
kristianpaul_yes_ i know for security low risk short circuit01:58
kristianpaulbut at the same time the 5v isolation/jumper was tought..01:58
kristianpauland is it very common? to found boards with this female connectors..01:59
cladamwthe 5V isolation/jumper will still be there. ;-) Inputs from list is always good.01:59
cladamwwell...put female header can let users to easiler build their own expansion board with even 40*2 male headers.02:00
kristianpauloh 40*2 !02:00
cladamwI'm not very conscientious and careful02:01
cladamw on design, so werner did very well on each steps for ask/open discussion though. ;-)02:01
kristianpaulwhat is the easy part?, some better easy "plug" or less mechical stress?02:01
cladamwshould be easiler plug in. ;-)02:02
kristianpaulfor example (to something recent) osmosdr board, have male connector and the pich i think is very common02:02
kristianpaulyes plug in is a must for expasion02:02
kristianpauleasy plug in*02:04
cladamwwpwrak, when we do routing, we'd probably need to add another one mechanical hole to give more strength.02:04
cladamwkristianpaul, oh, yeah...it's right angle row even can against unexpected plugin idea which is good.02:05
cladamwwpwrak, i'll finish draft today or tomorrow then call for list review this week. but seems we don't have any good idea on dmx insertion/removal now, right ?02:08
cladamwkristianpaul, it's pitch looks like 2.54mm, if yes, definitely common than 2.0mm.02:09
wpwrakcladamw: (extra leds) oh, you're planning to route them ? naw, i'd  just put TPs at the rows/cols, then people can do their own homework :)02:13
wpwrak(dmx) i have no clue about DMX :)02:15
cladamw(dmx) alright. ;-)02:15
kristianpauldmx insertion/removal detection? is not that more a software task?02:17
cladamwwpwrak, (extra leds) you means those 8 leds with controling by TPs(as being row/col control) only, not by fpga pins ?02:17
wpwrakkristianpaul: reasons for going to female: 1) female is more expensive than male. so it makes sense to have one female set on the M1 and one make set on each board, assuming there will be on average > 1 boards per M1.02:17
cladamwkristianpaul, we'd thought to try do such insertion/removal by hardware to have awareness not f/w. ;-)02:17
wpwrak2) male is VERY easy to source. 3) female is also better protected against accidental contact02:18
wpwrak(unused leds) TPs on LED_COL{2,3} and LED_ROW{0,1,2} would provide all the connectivity one would need to add extra leds02:21
wpwraki don't think we really want users to use them anyway. they're more "reserved for us"02:22
kristianpaul average > 1 boards per M1, good point !!02:22
wpwrake.g., if we decide we want even more blinkenlights, then we already know where to connect them02:22
kristianpaulyes yes, understood !02:26
cladamwwpwrak, (unused leds) TPs on LED_COL{2,3} and TPs on LED_ROW{0,1,2} too? and they are still connected to fpga as latest draft, right ?02:27
kristianpaulall options are good move it seems02:27
cladamwwpwrak, phew~ i was misunderstood and stupid to read your ideas though. man02:27
wpwrak(connected to fpga) you mean LED_COL3 ? yes. even though it's not used :)02:28
wpwrakactually, we should place the column TPs after the resistor02:28
cladamwwpwrak, wait... add 1*TP between R203 and D36, 1*TP between R202 and D30, and keep all LED_COL{2,3} connected to fpga, and place one TP on each LED_ROW line, am i all right ?02:34
cladamwalright, i edit them now....and confirm with you later....phew...02:35
wpwrakD35 through D41 would also be purely virtual. i.e., no footprints. not even DNP.02:35
wpwrakthe schematics should still show them, though. to illustrate the concept02:36
cladamwwpwrak, D34 ~ D41 also be purely virtual. i.e., no footprints. not even DNP. << don't know.02:38
wpwrakthere would be no footprints for D34-D41. we don't know where they would go anyway.02:40
cladamwremove 8 leds from D34 to D41 completely?02:43
wpwrakin the layout02:44
wpwrakthey still exist conceptually. they're just not implemented. so the schematics should show them.02:45
cladamwi edit first, sorry that i still can't understand 'exist conceptually'. :)02:47
wpwrakif you think it would be confusing, you could remove the component references. and/or replace the symbols with some drawing. whatever works :)02:47
wpwrak(conceptually) well, let's assume you have the full matrix as shown. like i did on my test board. then each LED has certain connections and it is controlled by a certain register in the led matrix controller.02:49
wpwraknow, remove the led (leave the footprint). this doesn't change the concept. just that the led isn't present anymore. but if you were to add it again, it would work in the same way as before.02:50
wpwraknow, go one step further and also remove the footprint. the concept is still the same, but you now have to connect to the right row/column lines to make the led work.02:51
wpwrakif you look at the schematics, the role and connectivity of the led will still be obvious.02:52
wpwrakthat's what i mean.02:52
kristianpauloh, there are MPU also, so is not  a full MMU02:52
wolfspraulkristianpaul: mpu / mmu ?02:53
wolfspraulwpwrak: I have a question about openscad. a while ago you were doing comparisons of scripted cad tools - cadmium, cgal, openscad02:54
wpwrakwolfspraul: yup02:54
wolfsprauldid you loot at blender too?02:54
wolfspraulthe openscad homepage immediately tries to explain the difference to blender, and I read that02:54
kristianpaulsorry i forgot question mark (?)02:54
wpwrakonly cadmium vs. openscad.as far as i recall, cgal is a library working underneath.02:54
kristianpaulwas reading abotu arm cortex cpu used on osmo-sdr ;)02:55
wolfspraulbut I'm still curious whether blender would be able to do this kind of 'cad'02:55
wolfsprauland it leads to my second question, which is where in the bigger toolchain/process you see openscad02:55
wpwrakblender is an enigma to me ;-)02:55
wolfspraul(btw, sorry, I just realize this may be better in #qi-hardware...)02:55
wolfspraulso the second question first then - what is the point/use case of the openscad files?02:55
wolfspraulis it just to make animations of the case, for advertisement/explaining/etc.02:56
wolfspraulor are the openscad files used as input to making parts?02:56
wpwraki suppose you could use the mesh for production. why not.02:57
wolfspraulok, and here's a m1 question ;-)03:00
wolfspraulI connected my LV3, but nothing happens right now (no surprise, old 2011-11 image)03:00
wolfspraulin fact the lv3 is always in some strange mode where the 'Sys' led blinks and nothing else is possible03:00
wolfspraulis that normal?03:00
wolfspraulif I press FX & Master together, Sys blinking will stop for a few seconds then resume03:00
wolfspraulI will first update my m1 image now03:01
wpwrakthe blinking indicates that it didn't enumerate. this is expected for anything that is older than commit 6ca46c228458a1cd5e2f94416cb7109c91f3727903:03
cladamwwpwrak, http://downloads.qi-hardware.com/hardware/milkymist_one/sch/tmp/MILKYMISTONE.pdf03:07
wpwrakcladamw: for the leds ?03:08
cladamwwpwrak, 1. two buttons circuits are removed 2. added TPs on matrix-led circuits.03:08
cladamwxiangfu, with your latest image for M1, can i still use argument '--rc3' ? and are there still bugs somewhere ?03:10
wpwrakcladamw: maybe add a comment next to SW2 explaining that there used to be SW1 and SW3 (and BTN1/3), but they're gone now.03:11
cladamwxiangfu, if i'd ship m1 today, is it stable ? or i should keep last image and don't use latest ?03:12
wpwrakrest looks good03:12
xiangfucladamw, reflash_m1.sh --rc3 will be same as before.03:13
cladamwwpwrak, okay. thanks. I'll later to realze conceipts for led. i can't digest it now though. need to work others. ;-)03:13
cladamwxiangfu, yes, is it stable ? i mean i'd like to ship m1 today. we should stick a very stable image for it.03:14
cladamwwpwrak, comments added. :)03:27
wpwrakkewl. thanks :) the reference to the state machine is a little enigmatic, though. we don't actually need that information here. it's enough to know that we only have one button.03:30
cladamwha~s/w guy should all know state machine idea, no ? hehe...03:33
wpwrakoh, i'm sure they do. but they will have no clue which state machine you're talking about :)03:34
wpwrakand those people who know what it is, are #milkymist residents anyway and don't need the comment ;-)03:35
wpwrakso you've created an explanation that can only be understood by those who don't need it :)03:35
cladamwalright, i'll remove. ;-)03:37
lekernelxiangfu: may I suggest I keep taking care of building/testing/uploading software images? (it allows me to do a few quality checks...)09:04
xiangfulekernel, yes. sure. why I do that is since I have a daily build. so I move the tested image to somewhere else.09:05
wolfspraullekernel: I think as a first step, xiangfu tries to increase the quality of builds, and actually more importantly the quality of the test plan, to the point that we can trust those images to be very well tested.09:35
wolfspraulthat includes testing with peripherals09:35
wolfspraulyou can choose to upload xiangfu's builds to milkymist.org or not (don't know whether xiangfu can or should upload himself, up to you)09:35
wolfspraulbut I think the more testing we do, and especially working on a better test plan, that's always a good thing. once we have figured this out, we should come out with meaningful updates every month, or at least bi-monthly. that's not necessarily something big, can be small things like new patches etc.09:36
lekernelwhat about xiangfu fixing relatively small bugs instead, like the video-in full screen not taking the parameters, or the UI problems that Yi and Werner mentioned?09:36
wolfspraulsure, first a good test plan, then fix the bugs that show up during testing09:37
lekernelthe bugs are known already, no need for additional test plans09:38
wolfspraulthat's too random for me. I start with a test plan. there are easily 1000 bugs that could be found or fixed in m1 today. so the question for our users is what incremental (regression-free) updates they can get next month, the following month, etc.09:39
lekerneland I do not think any of my images ever had a major regression09:39
lekernellet's fix things that actually cause problems, like those bugs09:39
Fallenoua test procedure is a good thing for frequent delivery (of good quality)09:39
Fallenoua procedure to follow before each release09:39
wolfspraulyes I don't disagree, but without a test plan we don't really know what we are building09:39
Fallenouto test for regressions09:39
lekernelI take care of this testing. I like to be reassured :p09:40
wolfspraulof course you can and should test. you have a unique test approach because you programmed so much of this stuff.09:41
wolfspraulbut I will continue to ask xiangfu with an independently thought-through and written test plan, and running through that test plan09:41
wolfspraulwhich includes testing with peripherals, walking through important use cases, etc. all of that documented and efficient (so we can repeat it for frequent updates)09:42
lekernelI believe his time would be better spent fixing bugs that actually cause problems for the users, not figuring out a test plan to address a non-existing issue09:42
wolfspraulI think we have been sort-of smart so far in combining forces effectively, so I'm optimistic going forward. xiangfu *is* fixing bugs, but we need a systematic way to identify which bugs to fix in which order.09:43
lekernelof course, I'm not fundamentally opposed to having such a test plan, but first things first09:43
wolfspraulnope. again. xiangfu works on test-plan driven bug fixing :-)09:43
wolfspraulsure, I think we mean roughly the same thing09:44
wolfspraulat this point, I believe you are still the best place to come out with strong regression-free updates - quick!09:44
lekernelwell, Werner already made a good list of bugs in this email, and in the November one09:44
wolfspraulbut it doesn't scale09:44
lekernelI don't think there's anything to add09:44
wolfsprauloh sure, I kno09:44
wolfspraulyes correct, like I said. xiangfu needs a simple test plan, build process, then prioritize and fix bugs.09:45
wolfspraulwithout build process and test plan it's too unfocused imho (I think I'm speaking for our regular users/buyers)09:45
wolfspraulwerner's mails easily give xiangfu (or anybody) enough work for years :-)09:45
wolfspraulgood work09:45
wolfspraulbut we need a process that allows us to come out with frequent regression-free updates, without bogging you or werner down too much09:46
wolfspraullekernel: if you can, just ignore xiangfu's builds and test plan :-) when we reach the quality level that *you* will like it, the issue goes away by itself. we are not there yet, xiangfu as-of-today is unable to make builds that I would trust, especially after bigger changes in the SoC or lower levels.09:48
lekernelbut I think he would be able to fix those small UI bugs, no?09:49
lekernelwhich as Yi pointed out are quite annoying09:49
wolfspraulyes of course09:49
wolfspraulthose 2 things go together - testing & bug fixing09:49
FallenouWell I don't think making such a test plan would take so much time09:50
Fallenouso better do it and then start fixing bugs09:50
Fallenoueven if it's a first draft which could be improved by feed backs afterward09:50
Fallenouit's not like it's a 4 days work09:50
Fallenouit's just writting a procedure to test before releasing if I understand correctly09:51
Fallenoushould not take a month :)09:51
lekerneland it'll become obsolete after major sw changes, ...09:51
Fallenouthat's a reason for not spending an entire week on it09:52
Fallenouit will change09:52
Fallenouso better do a quick first draft and then move on09:52
lekernelwe know what the existing bugs are. now all we need to do is fix them ...09:52
Fallenouquick draft is better than nothing09:52
Fallenouthere is a balance between tons of pointless procedures/integration test/unit testing etc and having no test procedure at all :)09:53
lekernelsince there have been no major regressions in releases so far, I don't think we're too far off from this balance09:55
FallenouYou are right, the test xiangfu you and wpwrak are doing seem to suffice09:56
Fallenoulet's just write it down :)09:56
Fallenouit's easy to miss something if it's not written down09:56
FallenouI'm sure you think it's a waste of time, but it's not a big one :p it should be like 1/2 days ?09:56
lekernelalso, software regressions are really no big deal. we can always upgrade (using the rescue mode)09:57
lekernel(as you can see, I did write a _hardware_ test plan)09:57
lekernelso... small probability * small impact = let's not give a rat's ass about this09:57
rejonOh testing would be helpful10:07
rejonthe more automated the better10:07
rejonthat would go well with automatic builds of the software10:07
rejoncould help more people get involved too10:07
rejonI wish we could give out a milli like google doing to find bugs in their software10:07
rejonbut not yet ;)10:07
rejonis there a link to automated builds?10:08
rejonsorry, I have been busy10:08
rejonon fabricatorz work10:08
wolfspraulrejon: yes, we are trying to share the testing work smarter among more people10:11
wolfspraulno worries :-)10:11
rejoncool, more the better...plus, automation can help find some routine things that we humans aren't so good at10:12
lekernelimo it would be better to share the annoying and small bugfixing work10:12
wpwrakwolfspraul: (work for years) naw, xiangfu is pretty quick with those gui fixes11:43
wpwrak(bugs to add) in fact, there's a bit of weirdness with my wireless combi keyboard: when i move the mouse over something, it very often selects. this doesn't happen with a normal mouse. haven't looked into this yet, because it could just be general usb madness. or maybe us being a bit too quick and dirty on the report format.11:49
wpwrak(automated testing) i have a bunch of regression tests for the compiler. 396 tests on last count, but that's a bit inflated because also each patch in the patch pool counts twice. but that's only the compiler, not all of FN. the audio/midi/etc. input -> rendering or -> gui flow would be much harder to test.12:21
wpwrak(test plan) a checklist can't hurt. complexity sneaks up on you. and software always gets more complex ;-)12:22
wpwraklekernel: (programming, motherfucker) actually, he's a bit of a fraud: http://programming-motherfucker.com/become.html12:31
wpwrakfirst he lists "languages" like pascal, java, php, ruby, or C#. and then the general books: "Patterns and Practices: Application Architecture Guide 2.0", "NASA Software Measurement Handbook", "Guide to the Software Engineering Body of Knowledge", ...12:36
wolfspraulwpwrak: did you see my list post about routing the analog line-out or s/pdif to the expansion headers?13:50
wpwrakwhen was that ?13:55
wolfspraula few hours ago I think13:56
wpwrakhmm. nothing here. strange.13:58
wpwraknothing in the archive either14:01
wpwrakmaybe the dragons manning the chinese firewall ate it ? :)14:02
Action: Fallenou has just been told he received his korg nanokontrol214:15
Action: Fallenou will play tonight14:15
wolfspraulnothing there?14:19
wolfspraulwell, I only asked whether it would make sense to put the analog line-out wires on the expansion header14:20
wolfsprauland/or the s/pdif ones14:20
wolfspraulwith the analog line-out, someone could build a (limited power, but still) amplifier expansion board :-)14:20
wpwrakhm, we have them on the audio headers. the original idea was to get rid of the audio header altogether. is it creeping back in ? :)14:23
wpwrakwe could place the audio header(s) such that they're easily reached from an expansion board. e.g., somewhere between the digital headers or on the side14:24
wolfspraulwe work on a much better defined 'expansion system' now that hopefully we can keep stable for years14:24
wolfsprauland I just saw this question about 'what more to put on the headers' and I thought how about analog line-out and s/pdif14:25
wpwrakbut sure if this wouldn't make routing messy, though. if sebastien is already worried about one highly robust fault indication line, ...14:25
wolfspraulwhether those lines were on another header before or not is not really an argument for or against them14:25
wpwrakno, but the original thought was that we can get rid of the header because nobody uses them14:26
wpwrakthen i suggested to at least keep DNP headers around, in case we were wrong and someone wants to use them14:26
wpwraknow you're bringing the connector completely back. so was the original reasoning incorrect ?14:27
wolfspraulnot back14:32
wolfspraulwe have new pins on the j21/j22 connectors14:32
wolfsprauland I was replying to "any other ideas for those wires"14:32
wpwrakhmm, that's just four new ones in total. so that would be either analog audio (needs four) or SPDIF (needs two)14:34
wpwrakand analog would be split between J21 and J22, which is probably a bad idea14:34
wpwrakbtw, assigning the "new" pins to ground serves a purpose: it can help to improve the ground return path (if routing is done properly)14:36
wpwrakand it will make "good" routing a bit easier in DIY boards, because you have GND on both sides14:38
kristianpaulMTK... what about FLTK.. argh but is C++ and this still not supporte on GCC right?..14:39
wpwrakC++ is evil. not supporting it is like denying the world the joy of the plague.14:43
kristianpaulok, still gtk 1 then :)14:48
wpwrakwolfspraul: so ... if you want to bring audio to the expansion boards, you'd either need even larger connectors or place the ones we have already planned somewhere where a board could reach them.14:51
lekernelFLTK requires X which is even shittier than C++14:51
wolfspraulwpwrak: alright then... I thought I bring it up14:52
wpwrakX is great. it has worked 20 years ago and still does to the present day. that's long-term stability for you :-)14:53
lekernelI already had this discussion and my position hasn't changed: X is only a source of bloat, slowness, and unwarranted complexity.14:54
wpwrakwolfspraul: we could route SPDIF to, say, J22. that would still leave the ground from J21 and thus weaken the ground quality only marginally. but then, SPDIF is probably of quite limited interest anyway.14:54
wpwrakanalog audio is much harder because it also comes with its own ground, doesn't like interferences, and so on.14:55
wolfspraulI thought of abusing the 5V supply to make an amplified with the line-out signals :-)14:55
wolfspraulmaybe that wouldn't even work if I knew a thing about amplifiers... but I am spared from such negativity :-)14:56
wpwrak2 x 5 W output. the M1 ghettoblaster ;-)14:56
lekernelbetter use a PWM from the FPGA and a class-D amplifier14:57
Hodapp"even shittier than C++"?!14:59
HodappI thought embedded hardware guys were supposed to love that language15:00
wpwrakin C we trust. but the "++" of "C++" is as necessary as appendix cancer15:02
HodappMy opinion kind of lines up with that of Linus Torvalds on a lot of matters. C++ is a shitty low-level language and an even shittier high-level language, but folks always pretend it excels at both.15:03
Hodappand I'd rather stick to C and not even pretend I'm using an OO language and overcomplicate the shit out of everything with some faux-OO model... or actually use something that lets me express abstraction properly.15:04
Hodappbut my degree is in EE, as much as I don't use it. I like being able to hook up a debugger and see what is going on, rather than seeing some IPluginCustomDataRetrievalSingletonInstanceHandlerFunctorCallback where it hits the vtable and inexplicably jumps straight to nowhere.15:09
wpwrakvery good :) plus, you can program in OO-style in C just fine. C++ only "helps" you with the things that make your code hard to maintain.15:10
wpwrakheh :)15:10
Hodappno, design patterns are evidence that your language fucking sucks15:10
HodappBut one thing I ran into when porting a big C++ app over to Linux was some mysterious crashes where I was digging down all the way to the x86 assembly where it was hitting a vtable, and then making a jump to nowhere.15:12
HodappAll the C++ folks could tell me was basically "Well... You're not supposed to know about any of the specifics there, because things like this just never happen."15:12
HodappSomeone else rant, so I don't.15:17
Action: Fallenou just plugged his korg nanoKontrol218:14
Action: Fallenou reading http://downloads.qi-hardware.com/software/images/Milkymist_One/latest/doc/midi.pdf18:17
Fallenouwpwrak: how could I do a simple test with the korg nanokontrol2 and the M1 ?18:38
lekernelopen the midi settings and play with the controls18:50
kristianpaulFallenou: good, does it work? :19:18
Fallenoulekernel: I opened the "midi settings" and I am a bit lost19:28
Fallenouwhat can I do ?19:28
Fallenouthe korg top left hand corner LED is not lite19:28
Fallenounothing happens when I play with the controls19:31
Fallenouhum in the console I get "Retry count exceeded, disablin device"19:34
Fallenoutwo times19:34
FallenouI tried without the USB mouse, with only the korg connected, same thing19:35
GitHub104[migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/7f307c54a932985b629482746f7127c77083e8d219:36
GitHub104[migen/master] README: clarify license - Sebastien Bourdeauducq19:36
lekernelFallenou: sounds you have hit one of those pesky USB bugs. either fix it or wait ...19:37
lekernelin the meantime, you can tunnel messages through OSC19:38
FallenouI think I will focus on MMU not to lose too much of the very limited time I have19:38
FallenouI will try with OSC19:38
Fallenouis there some kind of OSC tutorial/how to somewhere ?19:38
Fallenouhttp://opensoundcontrol.org/implementation/milkymist-one < ahah nice :)19:41
Action: Fallenou checked and his nanoKontrol2 firmware version is 1.03 (up to date)19:50
Fallenoulekernel wpwrak < I updated to developer snapshot, the latest one ( soc 1.2 flickernoise 1.2 26 feb 2012) and now korg usb midi controller works :)20:43
Fallenouit's detected by navre (I can see it in the uart) and the "latest active controller" is moving when I move faders20:43
kristianpaulparty ! :)20:43
lekernelah, of course if you didn't upgrade, it had little chance of working *g*20:59
Fallenouyep I was still using the factory firmware ;)21:02
FallenouI spent like 3 minutes on Rain Dance MIDI RMX patch with like 0 result21:02
Fallenoujust a point or so21:03
Fallenouand now I'm playing like crazy21:03
FallenouI can make very nice visuals now that I understand the controls mapped :)21:03
wpwrakwelcome to the MIDI club ! ;-)21:18
Fallenouhehe thanks =)21:20
Fallenouthe wave scale is quite responsive21:21
Fallenouit could be a good idea to divide it a little21:21
Fallenouhehe midi4 * 2021:21
Fallenoumaybe midi4*5 :p21:21
Fallenouhttp://lockerz.com/s/188327561 a picture of the play area :)21:31
wpwrakyes, midi4 is a bit trigger-happy. but there are configurations where a large amplitude looks good21:33
wpwrakif you look at patches/demo/raindance/raindance.fnp, you'll see a different approach: *10 but with an encoder added, so i can "tune it up" as far as i want21:35
Fallenouby encoder you mean the rotative button at the top ?21:35
wpwraka rotary encoder. the nanoKONTROL doesn't have that21:36
Fallenouoh ok21:36
wpwrakyou could mix it with a pot, though. a bit less flexible but you kinda get the same effect21:36
Fallenouif I put zoom = midiN21:37
wpwrak(photo) looks pretty good :)21:37
Fallenouzoom is between 0 and 1, right ?21:37
FallenoumidiN between 0 and 12721:37
wpwrakmidiN usually 0-121:37
Fallenouwill it be divided automagically ? or do I need to do miniN/127 ?21:37
Fallenouoh ok21:37
Fallenouit's already divided :o21:37
Fallenou(photo) taken with a HTC desire, not a nice camera ^^21:38
wpwrakzoom .. 1 = no zoom, < 1 = shrinks, > 1 = grows. not sure what the practical limit it21:44
Fallenouit's nice to move the wave to the right on the X axis and then activate rotation :)21:48
Fallenouand a bit of zoom in21:48
Fallenougn8 !23:04
--- Thu Mar 1 201200:00

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