Topic for #milkymist is now Radical Tech Coalition :: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
cladamw has joined #milkymist
cladamw has joined #milkymist
cladamw has joined #milkymist
cladamw has joined #milkymist
xiangfu has joined #milkymist
xiangfu has joined #milkymist
<wolfspraul>
cladamw: good morning!
<wolfspraul>
so - how's R4 going?
<cladamw>
wolfspraul, good morning!
<cladamw>
1. will keep only one middle button by using state machine for the button behaviour proposed by Werner. this just to remove two buttons..
<wolfspraul>
good
<wolfspraul>
switch to 10*2 header
<cladamw>
2. (J21/J22 connector size) wait a bit, seems only kristianpaul replied. ;-)
<cladamw>
but draft already edited with 10*2 female headers, no big sourcing issue.
<wolfspraul>
everything else settled?
<wolfspraul>
how about the ddc5v current limiting now?
<wolfspraul>
the last mail was from sebastien who said he liked the micrel switch but felt the en & fault lines were excessive
<wolfspraul>
I think, lemme re-read
<cladamw>
3. (
<cladamw>
DVI-I DDC5V) from S
<wolfspraul>
yes
<wolfspraul>
or nothing at all, and connect to 5V directly
<wolfspraul>
I even prefer that, but it's not a technical reason, just economical and gut feeling.
<wolfspraul>
so what do we do? micrel ic + test points?
<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.
<wolfspraul>
pah
<wolfspraul>
:-)
<wolfspraul>
I think we already broke it several times
<wolfspraul>
first going from male to female, adding a second connector, now another row? :-)
<wolfspraul>
no problem I think
<cladamw>
wolfspraul, okay, then done on 10*2. ;-)
<wolfspraul>
it is still possible to hookup old expansion boards on R4, just (even more) hacky
<wolfspraul>
sourcing improvements are very important though, I really want to build the entire m1 out of easy-to-source parts
<wolfspraul>
that's an important objective
<cladamw>
wpwrak, to last DDC5V replied thread by Sebastien, how's your thinking now? micrel ic + test points?
<wolfspraul>
yes
<wolfspraul>
don't ask him
<wolfspraul>
:-)
<cladamw>
ha...he'll mad? ;-) if yes, sorry. :)
<wolfspraul>
oh no, all relaxed
<wolfspraul>
test points is a good compromise I think
<wolfspraul>
if werner totally cannot live with that, he will speak up ;-)
<cladamw>
okay. so I'll edit them today.
<wolfspraul>
so we go into routing soon?
<cladamw>
not yet...so we finised all dmx/video insertion/removal? i don't think so. ;-)
<cladamw>
one another thing is how we placement those 'reserved' matrix-led ? i think wener should have his good idea. ;-)
<wpwrak>
wolfspraul: (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 :)
<wpwrak>
(routing) i think we should first call for a public schematics review
<cladamw>
wpwrak, we still have 8 reserved matrix-led, do you remember them ?
<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.
<cladamw>
see Misc.SchDoc. ;-) what you mean is let house to place them as convenience as they want ?
netru has joined #milkymist
netru has joined #milkymist
<kristianpaul>
cladamw: oh, Hi
<cladamw>
I'd rather place those 8 to be together in top side and/or close to board edge or somewhere.
<cladamw>
kristianpaul, thanks for your inputs. ;-)
<kristianpaul>
well all is okay, what you already had decided is is good, so any mechanical situation well, you know more than me
<kristianpaul>
btw i dint understood at the end why moved to female
<kristianpaul>
_yes_ i know for security low risk short circuit
<kristianpaul>
but at the same time the 5v isolation/jumper was tought..
<kristianpaul>
and is it very common? to found boards with this female connectors..
<cladamw>
the 5V isolation/jumper will still be there. ;-) Inputs from list is always good.
<kristianpaul>
great
<cladamw>
well...put female header can let users to easiler build their own expansion board with even 40*2 male headers.
<kristianpaul>
oh 40*2 !
<cladamw>
I'm not very conscientious and careful
<cladamw>
on design, so werner did very well on each steps for ask/open discussion though. ;-)
<kristianpaul>
what is the easy part?, some better easy "plug" or less mechical stress?
<cladamw>
should be easiler plug in. ;-)
<kristianpaul>
for example (to something recent) osmosdr board, have male connector and the pich i think is very common
<cladamw>
wpwrak, when we do routing, we'd probably need to add another one mechanical hole to give more strength.
hypermodern has joined #milkymist
hypermodern has joined #milkymist
<cladamw>
kristianpaul, oh, yeah...it's right angle row even can against unexpected plugin idea which is good.
<cladamw>
wpwrak, 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 ?
<cladamw>
kristianpaul, it's pitch looks like 2.54mm, if yes, definitely common than 2.0mm.
<kristianpaul>
good
<wpwrak>
cladamw: (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 :)
<wpwrak>
(dmx) i have no clue about DMX :)
<cladamw>
(dmx) alright. ;-)
<kristianpaul>
dmx insertion/removal detection? is not that more a software task?
<cladamw>
wpwrak, (extra leds) you means those 8 leds with controling by TPs(as being row/col control) only, not by fpga pins ?
<wpwrak>
kristianpaul: 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.
<cladamw>
kristianpaul, we'd thought to try do such insertion/removal by hardware to have awareness not f/w. ;-)
<wpwrak>
2) male is VERY easy to source. 3) female is also better protected against accidental contact
<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 leds
<wpwrak>
i don't think we really want users to use them anyway. they're more "reserved for us"
<kristianpaul>
average > 1 boards per M1, good point !!
<wpwrak>
e.g., if we decide we want even more blinkenlights, then we already know where to connect them
<kristianpaul>
yes yes, understood !
<cladamw>
wpwrak, (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 ?
<kristianpaul>
all options are good move it seems
<cladamw>
wpwrak, phew~ i was misunderstood and stupid to read your ideas though. man
<wpwrak>
(connected to fpga) you mean LED_COL3 ? yes. even though it's not used :)
<wpwrak>
actually, we should place the column TPs after the resistor
<cladamw>
wpwrak, 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 ?
<wpwrak>
yeah
<cladamw>
alright, i edit them now....and confirm with you later....phew...
<wpwrak>
D35 through D41 would also be purely virtual. i.e., no footprints. not even DNP.
<wpwrak>
the schematics should still show them, though. to illustrate the concept
wolfspraul has joined #milkymist
wolfspraul has joined #milkymist
<cladamw>
wpwrak, D34 ~ D41 also be purely virtual. i.e., no footprints. not even DNP. << don't know.
wolfspraul has joined #milkymist
wolfspraul has joined #milkymist
<wpwrak>
there would be no footprints for D34-D41. we don't know where they would go anyway.
<cladamw>
remove 8 leds from D34 to D41 completely?
<wpwrak>
in the layout
<wpwrak>
they still exist conceptually. they're just not implemented. so the schematics should show them.
<cladamw>
i edit first, sorry that i still can't understand 'exist conceptually'. :)
<wpwrak>
if you think it would be confusing, you could remove the component references. and/or replace the symbols with some drawing. whatever works :)
<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.
<wpwrak>
now, 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.
<wpwrak>
now, 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.
<wpwrak>
if you look at the schematics, the role and connectivity of the led will still be obvious.
<wpwrak>
that's what i mean.
<kristianpaul>
oh, there are MPU also, so is not a full MMU
<wolfspraul>
kristianpaul: mpu / mmu ?
<wolfspraul>
wpwrak: I have a question about openscad. a while ago you were doing comparisons of scripted cad tools - cadmium, cgal, openscad
<wpwrak>
wolfspraul: yup
<wolfspraul>
did you loot at blender too?
<wolfspraul>
the openscad homepage immediately tries to explain the difference to blender, and I read that
<kristianpaul>
sorry i forgot question mark (?)
<wpwrak>
only cadmium vs. openscad.as far as i recall, cgal is a library working underneath.
<kristianpaul>
was reading abotu arm cortex cpu used on osmo-sdr ;)
<wolfspraul>
but I'm still curious whether blender would be able to do this kind of 'cad'
<wolfspraul>
and it leads to my second question, which is where in the bigger toolchain/process you see openscad
<wpwrak>
blender is an enigma to me ;-)
<wolfspraul>
(btw, sorry, I just realize this may be better in #qi-hardware...)
<wolfspraul>
so the second question first then - what is the point/use case of the openscad files?
<wolfspraul>
is it just to make animations of the case, for advertisement/explaining/etc.
<wolfspraul>
or are the openscad files used as input to making parts?
<wpwrak>
i suppose you could use the mesh for production. why not.
<wolfspraul>
ok, and here's a m1 question ;-)
<wolfspraul>
I connected my LV3, but nothing happens right now (no surprise, old 2011-11 image)
<wolfspraul>
in fact the lv3 is always in some strange mode where the 'Sys' led blinks and nothing else is possible
<wolfspraul>
is that normal?
<wolfspraul>
if I press FX & Master together, Sys blinking will stop for a few seconds then resume
<wolfspraul>
I will first update my m1 image now
<wpwrak>
the blinking indicates that it didn't enumerate. this is expected for anything that is older than commit 6ca46c228458a1cd5e2f94416cb7109c91f37279
<cladamw>
wpwrak, 1. two buttons circuits are removed 2. added TPs on matrix-led circuits.
rejon_ has joined #milkymist
rejon_ has joined #milkymist
<cladamw>
xiangfu, with your latest image for M1, can i still use argument '--rc3' ? and are there still bugs somewhere ?
<wpwrak>
cladamw: maybe add a comment next to SW2 explaining that there used to be SW1 and SW3 (and BTN1/3), but they're gone now.
<cladamw>
xiangfu, if i'd ship m1 today, is it stable ? or i should keep last image and don't use latest ?
<wpwrak>
rest looks good
<xiangfu>
cladamw, reflash_m1.sh --rc3 will be same as before.
<cladamw>
wpwrak, okay. thanks. I'll later to realze conceipts for led. i can't digest it now though. need to work others. ;-)
<cladamw>
xiangfu, yes, is it stable ? i mean i'd like to ship m1 today. we should stick a very stable image for it.
<cladamw>
wpwrak, comments added. :)
<wpwrak>
kewl. 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.
<cladamw>
ha~s/w guy should all know state machine idea, no ? hehe...
<wpwrak>
oh, i'm sure they do. but they will have no clue which state machine you're talking about :)
<wpwrak>
and those people who know what it is, are #milkymist residents anyway and don't need the comment ;-)
<wpwrak>
so you've created an explanation that can only be understood by those who don't need it :)
<cladamw>
alright, i'll remove. ;-)
cladamw has joined #milkymist
cladamw has joined #milkymist
cladamwa has joined #milkymist
cladamwa has joined #milkymist
rejon has joined #milkymist
rejon has joined #milkymist
cladamwa has joined #milkymist
cladamwa has joined #milkymist
km2 has joined #milkymist
km2 has joined #milkymist
Martoni has joined #milkymist
Martoni has joined #milkymist
wolfspraul has joined #milkymist
wolfspraul has joined #milkymist
cladamw has joined #milkymist
cladamw has joined #milkymist
<lekernel>
xiangfu: may I suggest I keep taking care of building/testing/uploading software images? (it allows me to do a few quality checks...)
<xiangfu>
lekernel, yes. sure. why I do that is since I have a daily build. so I move the tested image to somewhere else.
<xiangfu>
:-)
wolfspraul has joined #milkymist
wolfspraul has joined #milkymist
<wolfspraul>
lekernel: 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.
<wolfspraul>
that includes testing with peripherals
<wolfspraul>
you 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)
<wolfspraul>
but 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.
<lekernel>
what 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?
<wolfspraul>
sure, first a good test plan, then fix the bugs that show up during testing
<lekernel>
the bugs are known already, no need for additional test plans
<wolfspraul>
that'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.
<lekernel>
and I do not think any of my images ever had a major regression
<lekernel>
let's fix things that actually cause problems, like those bugs
<Fallenou>
a test procedure is a good thing for frequent delivery (of good quality)
<Fallenou>
a procedure to follow before each release
<wolfspraul>
yes I don't disagree, but without a test plan we don't really know what we are building
<Fallenou>
to test for regressions
<lekernel>
I take care of this testing. I like to be reassured :p
<wolfspraul>
of course you can and should test. you have a unique test approach because you programmed so much of this stuff.
<wolfspraul>
but I will continue to ask xiangfu with an independently thought-through and written test plan, and running through that test plan
<wolfspraul>
which includes testing with peripherals, walking through important use cases, etc. all of that documented and efficient (so we can repeat it for frequent updates)
<lekernel>
I 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 issue
<wolfspraul>
I 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.
<lekernel>
of course, I'm not fundamentally opposed to having such a test plan, but first things first
<wolfspraul>
nope. again. xiangfu works on test-plan driven bug fixing :-)
<wolfspraul>
sure, I think we mean roughly the same thing
<wolfspraul>
at this point, I believe you are still the best place to come out with strong regression-free updates - quick!
<lekernel>
well, Werner already made a good list of bugs in this email, and in the November one
<wolfspraul>
but it doesn't scale
<lekernel>
I don't think there's anything to add
<wolfspraul>
oh sure, I kno
<wolfspraul>
know
<wolfspraul>
yes correct, like I said. xiangfu needs a simple test plan, build process, then prioritize and fix bugs.
<wolfspraul>
without build process and test plan it's too unfocused imho (I think I'm speaking for our regular users/buyers)
<wolfspraul>
werner's mails easily give xiangfu (or anybody) enough work for years :-)
<wolfspraul>
good work
<wolfspraul>
but we need a process that allows us to come out with frequent regression-free updates, without bogging you or werner down too much
<wolfspraul>
bbiab
<wolfspraul>
lekernel: 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.
<lekernel>
but I think he would be able to fix those small UI bugs, no?
<wolfspraul>
sure
<lekernel>
which as Yi pointed out are quite annoying
<wolfspraul>
yes of course
<wolfspraul>
those 2 things go together - testing & bug fixing
<Fallenou>
Well I don't think making such a test plan would take so much time
<Fallenou>
so better do it and then start fixing bugs
<Fallenou>
even if it's a first draft which could be improved by feed backs afterward
<Fallenou>
it's not like it's a 4 days work
<Fallenou>
it's just writting a procedure to test before releasing if I understand correctly
<Fallenou>
should not take a month :)
<lekernel>
and it'll become obsolete after major sw changes, ...
<Fallenou>
that's a reason for not spending an entire week on it
<Fallenou>
it will change
<Fallenou>
so better do a quick first draft and then move on
<lekernel>
we know what the existing bugs are. now all we need to do is fix them ...
<lekernel>
programming-motherfucker.com
<Fallenou>
quick draft is better than nothing
<Fallenou>
ahah
<Fallenou>
there is a balance between tons of pointless procedures/integration test/unit testing etc and having no test procedure at all :)
<lekernel>
since there have been no major regressions in releases so far, I don't think we're too far off from this balance
<Fallenou>
You are right, the test xiangfu you and wpwrak are doing seem to suffice
<Fallenou>
let's just write it down :)
<Fallenou>
it's easy to miss something if it's not written down
<Fallenou>
I'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 ?
<lekernel>
also, software regressions are really no big deal. we can always upgrade (using the rescue mode)
<lekernel>
(as you can see, I did write a _hardware_ test plan)
<lekernel>
so... small probability * small impact = let's not give a rat's ass about this
<rejon>
Oh testing would be helpful
<rejon>
the more automated the better
<rejon>
that would go well with automatic builds of the software
<rejon>
could help more people get involved too
<rejon>
I wish we could give out a milli like google doing to find bugs in their software
<rejon>
but not yet ;)
<rejon>
is there a link to automated builds?
<rejon>
sorry, I have been busy
<rejon>
on fabricatorz work
<wolfspraul>
rejon: yes, we are trying to share the testing work smarter among more people
<wolfspraul>
no worries :-)
<rejon>
cool, more the better...plus, automation can help find some routine things that we humans aren't so good at
<lekernel>
imo it would be better to share the annoying and small bugfixing work
<wpwrak>
wolfspraul: (work for years) naw, xiangfu is pretty quick with those gui fixes
<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.
cladamw has joined #milkymist
cladamw has joined #milkymist
<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.
<wpwrak>
(test plan) a checklist can't hurt. complexity sneaks up on you. and software always gets more complex ;-)
<wpwrak>
first 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", ...
<wolfspraul>
wpwrak: did you see my list post about routing the analog line-out or s/pdif to the expansion headers?
<wpwrak>
when was that ?
<wolfspraul>
a few hours ago I think
<wpwrak>
hmm. nothing here. strange.
<wpwrak>
nothing in the archive either
<wpwrak>
maybe the dragons manning the chinese firewall ate it ? :)
* Fallenou
has just been told he received his korg nanokontrol2
* Fallenou
will play tonight
<wolfspraul>
strange
<wolfspraul>
nothing there?
<wolfspraul>
well, I only asked whether it would make sense to put the analog line-out wires on the expansion header
<wolfspraul>
and/or the s/pdif ones
<wolfspraul>
with the analog line-out, someone could build a (limited power, but still) amplifier expansion board :-)
<wpwrak>
hm, we have them on the audio headers. the original idea was to get rid of the audio header altogether. is it creeping back in ? :)
<wpwrak>
we 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 side
<wolfspraul>
we work on a much better defined 'expansion system' now that hopefully we can keep stable for years
<wolfspraul>
and I just saw this question about 'what more to put on the headers' and I thought how about analog line-out and s/pdif
<wpwrak>
but sure if this wouldn't make routing messy, though. if sebastien is already worried about one highly robust fault indication line, ...
<wolfspraul>
whether those lines were on another header before or not is not really an argument for or against them
<wpwrak>
no, but the original thought was that we can get rid of the header because nobody uses them
<wpwrak>
then i suggested to at least keep DNP headers around, in case we were wrong and someone wants to use them
<wpwrak>
now you're bringing the connector completely back. so was the original reasoning incorrect ?
<wolfspraul>
not back
<wolfspraul>
we have new pins on the j21/j22 connectors
<wolfspraul>
and I was replying to "any other ideas for those wires"
<wpwrak>
hmm, that's just four new ones in total. so that would be either analog audio (needs four) or SPDIF (needs two)
<wpwrak>
and analog would be split between J21 and J22, which is probably a bad idea
<wpwrak>
btw, assigning the "new" pins to ground serves a purpose: it can help to improve the ground return path (if routing is done properly)
<wpwrak>
and it will make "good" routing a bit easier in DIY boards, because you have GND on both sides
<kristianpaul>
MTK... what about FLTK.. argh but is C++ and this still not supporte on GCC right?..
LmAt has joined #milkymist
LmAt has joined #milkymist
<wpwrak>
C++ is evil. not supporting it is like denying the world the joy of the plague.
<kristianpaul>
lol
<kristianpaul>
ok, still gtk 1 then :)
<wpwrak>
wolfspraul: 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.
<lekernel>
FLTK requires X which is even shittier than C++
<wolfspraul>
wpwrak: alright then... I thought I bring it up
<wpwrak>
X is great. it has worked 20 years ago and still does to the present day. that's long-term stability for you :-)
<kristianpaul>
*g*
<lekernel>
I already had this discussion and my position hasn't changed: X is only a source of bloat, slowness, and unwarranted complexity.
<wpwrak>
wolfspraul: 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.
<wpwrak>
analog audio is much harder because it also comes with its own ground, doesn't like interferences, and so on.
<wolfspraul>
I thought of abusing the 5V supply to make an amplified with the line-out signals :-)
<wolfspraul>
amplifier
<wolfspraul>
maybe that wouldn't even work if I knew a thing about amplifiers... but I am spared from such negativity :-)
<wpwrak>
2 x 5 W output. the M1 ghettoblaster ;-)
<lekernel>
better use a PWM from the FPGA and a class-D amplifier
<Hodapp>
"even shittier than C++"?!
<Hodapp>
I thought embedded hardware guys were supposed to love that language
<wpwrak>
in C we trust. but the "++" of "C++" is as necessary as appendix cancer
<Hodapp>
My 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.
<Hodapp>
and 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.
<Hodapp>
but 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.
<wpwrak>
very 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.
<wpwrak>
heh :)
<Hodapp>
HEY, LOOK, DESIGN PATTERNS MAKE OUR CODE ROBUST
<Hodapp>
no, design patterns are evidence that your language fucking sucks
<Hodapp>
But 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.
<Hodapp>
All 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."
* Fallenou
checked and his nanoKontrol2 firmware version is 1.03 (up to date)
<Fallenou>
lekernel 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 :)
<kristianpaul>
:D
<Fallenou>
it's detected by navre (I can see it in the uart) and the "latest active controller" is moving when I move faders
<kristianpaul>
party ! :)
rhinoplatform has joined #milkymist
<lekernel>
ah, of course if you didn't upgrade, it had little chance of working *g*
<Fallenou>
hehe
<Fallenou>
yep I was still using the factory firmware ;)
<Fallenou>
I spent like 3 minutes on Rain Dance MIDI RMX patch with like 0 result
<Fallenou>
just a point or so
<Fallenou>
and now I'm playing like crazy
<Fallenou>
I can make very nice visuals now that I understand the controls mapped :)
<wpwrak>
welcome to the MIDI club ! ;-)
<Fallenou>
hehe thanks =)
<Fallenou>
the wave scale is quite responsive
<Fallenou>
it could be a good idea to divide it a little
<wpwrak>
yes, midi4 is a bit trigger-happy. but there are configurations where a large amplitude looks good
<wpwrak>
if 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 want
<Fallenou>
by encoder you mean the rotative button at the top ?
<wpwrak>
a rotary encoder. the nanoKONTROL doesn't have that
<Fallenou>
oh ok
<wpwrak>
you could mix it with a pot, though. a bit less flexible but you kinda get the same effect
<Fallenou>
ok
<Fallenou>
if I put zoom = midiN
<wpwrak>
(photo) looks pretty good :)
<Fallenou>
zoom is between 0 and 1, right ?
<Fallenou>
midiN between 0 and 127
<wpwrak>
midiN usually 0-1
<Fallenou>
will it be divided automagically ? or do I need to do miniN/127 ?
<Fallenou>
oh ok
<Fallenou>
it's already divided :o
<Fallenou>
(photo) taken with a HTC desire, not a nice camera ^^
<wpwrak>
zoom .. 1 = no zoom, < 1 = shrinks, > 1 = grows. not sure what the practical limit it
<wpwrak>
s/it/is/
<Fallenou>
ok
<Fallenou>
it's nice to move the wave to the right on the X axis and then activate rotation :)