Topic for #milkymist is now Milkymist One, Milkymist SoC & Flickernoise development channel (LLHDL/Antares are welcome too) :: Logs: http://en.qi-hardware.com/mmlogs :: JFDI
_whitelogger joined #milkymist
Topic for #milkymist is now Milkymist One, Milkymist SoC & Flickernoise development channel (LLHDL/Antares are welcome too) :: Logs: http://en.qi-hardware.com/mmlogs :: JFDI
xiangfu joined #milkymist
aw_ joined #milkymist
aw joined #milkymist
rejon_ joined #milkymist
<stekern>
ok, so the first impressions of M1: 1) it'd be nice to have video signal out as quick as possible after pressing the power on button. The slight power on delay isn't bad, but the first time you turn it on you got a couple of seconds of wondering "is this thing working?"
<stekern>
2) a level meter next to the line in and mic in settings could be useful
<stekern>
otherwise, I got a positive first impression of it. buttons are intuitive etc
<stekern>
the video in<->patch mixing is really cool, that's definitely the killer feature of it
<wpwrak>
stekern: (standby mode) everybody hates it but sebastien :)
<wpwrak>
agreed on 2)
<wpwrak>
though if you add controls, it doesn't matter that much. then you can just adjust the effect there
<stekern>
you're probably right, I haven't got that far yet
<stekern>
I've got one mouse acting up, the pointer is just flying around like crazy
<wpwrak>
are you running the original firmware ?
<stekern>
I have a suspicion it might be the sensitivity of it that is the problem
<stekern>
well "original" as in the one that got installed after I pressed "update from web"
<stekern>
(which worked great btw)
<wpwrak>
good. that already gets you past a few nasty problems
<wpwrak>
i have a mouse that hardly moves with M1. linux likes it. so there appears to be some sensitivity magic indeed.
<stekern>
I'll take a look at it as soon as I have figured out how to tinker with this thing ;)
<stekern>
my mouse is pretty "jumpy" when connected to a computer too, I have to adjust the "speed" setting down when using it
<xiangfu>
wpwrak, how about more buttons can be software bind to patch variables?
<xiangfu>
wpwrak, oh. midi controller can do that thing.
<wpwrak>
yes. and we need a LOT more midiN variables :)
<wpwrak>
the LV3 alone can use something like 54 variables
<wolfspraul>
stekern: phew, I'm glad to hear overall you liked it! yuhuuu! :-)
<wolfspraul>
you probably know how insanely hard it is to actually get a completely new product to that level...
<wolfspraul>
of course there are many rough edges but let's take it on!
<stekern>
oh, as an engineer I'm very impressed
<wolfspraul>
let's fix the next 100 rough edges now :-)
<wolfspraul>
and then the following 500
<wolfspraul>
he he
<wolfspraul>
I think if you are not turned off by your initial impression of it, the you made it in terms of liking where this thing goes.
<wolfspraul>
good
<wolfspraul>
coffee now
<wolfspraul>
good morning btw
<wolfspraul>
wpwrak: great to you hear you got your LV3
<wolfspraul>
you say it's only understood partially, but that means something goes through already?
<wolfspraul>
I thought it's full-speed and not working yet? Or is full-speed already working as well?
<wpwrak>
it sends on several channels while M1 listens only on one. but i can teach midi2osc to do a bit of remapping :)
<wpwrak>
currently going via the PC. we don't have usb-midi yet
<stekern>
a midi comment: channels are usually numbered 1-16 apposed to 0-15
<wpwrak>
maybe we should use roman numerals :)
<stekern>
:)
<wolfspraul>
wpwrak: how do you like lv3 mechanically?
<wpwrak>
feels pretty good. the joysticks are very small, so you have to be careful with them
<wpwrak>
not really suitable for how i (ab)used the pad so far. but that may not be a problem
<wpwrak>
i need to see how they perform for 2D
<wpwrak>
the faders are much better quality than the junk i have on the nanoKONTROL2
<wpwrak>
about on par with the (larger) fader on the Kaossilator
<wpwrak>
the overall feel is it's a precision instrument. that's a bit at odds with the idea that milkymist unleashes the beast inside the VJ. but let's see.
wolfspraul joined #milkymist
DJTachyon joined #milkymist
<wpwrak>
the joysticks should be ideal for killing M1s with the original firmware (which has the queue bug). they move by less than 25 mm end to end and they move very easily. so with a little push, you can send a LOT of MIDI messages in no time :)
<wpwrak>
hmm, shouldn't i be able to ftp to the M1 ?
<wpwrak>
ftp says "error creating file"
<wpwrak>
konqueror says it can't rename the file
<xiangfu>
wpwrak, try the command line tools.
<xiangfu>
I also have problem when copy file to M1 by using 'nautilus'
<xiangfu>
old version 'nautilus' is ok. after update my system it's broken.
<wpwrak>
renamed the file. now it works. yay ! :)
aw_ joined #milkymist
aw joined #milkymist
aw_ joined #milkymist
<aw_>
wpwrak, the parts for reset and usb circuits are on the way to my site. since i received shipment notice from AVNET but without Fedex tracking #.
<aw_>
I'll email AVNET for tracking #. but I think the shipment should be soon coming. ;-)
<wolfspraul>
aw_: do you have the adv7181c at your site already?
<wolfspraul>
if not - are they ordered?
<wolfspraul>
maybe we should add that verification as well
<aw_>
the shipment includes 5pcs 7181c, so yes I surely will replace it.
<aw_>
so once I get parts, I'll replace/rework the proposed circuit of reset & usb-switch on _TWO_ rc3 boards to see if they can still work well.
<wolfspraul>
yes
<wolfspraul>
and also 7181c
<aw_>
supposedly they must be. If not, that's always my soldering problem first. ;-)
<wolfspraul>
for the adv7181c, we have to remove some filter as well
<wolfspraul>
is it clear what exact parts need to be removed?
<aw_>
then I still need to update rc3 know issue wiki page for more histories records, but that page I included two proposed circuits for rc4 design verification already. ;-)
<wolfspraul>
I think I tried to clarify that a few times, but cannot find on the wiki page
<wolfspraul>
"capacitors and ferrite beads near the video connectors"
<wolfspraul>
aw_: do you understand what exactly that is?
<aw_>
mm...I can search them. I knew you all talked a lot then for remove alias filters.
<wolfspraul>
I think we clarified it once, searching...
<aw_>
hey...seems you wanted me do this now..phew... :(
<aw_>
there's only one about "total of 14 new leds proposed" that I don't know. ;-)
<wolfspraul>
aw_: I tell you more about that later, have to run to a meeting with Jon now
<aw_>
may be still under discussions these days. ;-)
<wolfspraul>
yes
<wolfspraul>
no worries
<wolfspraul>
open project, always some discussion somewhere, right? :-)
<aw_>
ha..good . okay. :)
<aw_>
sure. right.
<aw_>
okay...work for another. ;-)
<wolfspraul>
wpwrak: btw, tool question
<wolfspraul>
say Adam or anybody wants to draw a quick partial circuit/schematic as part of a discussion
<wolfspraul>
Adam is just using a pen and his hand, and then a camera and upload
<wolfspraul>
not bad, it's quick
<wolfspraul>
is there any quick and easy tool you would propose?
<wolfspraul>
maybe something that can convert a super simple textual expression into a graphic?
<wolfspraul>
of course it could be entered into kicad, but that looks like overhead and would certainly be slower than just drawing by hand and photographing as Adam does
<wolfspraul>
the tool would need to compete with the speed of a hand-drawing/photo
<wolfspraul>
bbiab
<aw_>
wpwrak, let me know if i can help you some. ;-)
<wpwrak>
lekernel: btw, would image rotation also be possible ? or would that get difficult ?
<lekernel>
the TMU can only blit to a rectangular surface, so you'd get clipping
<lekernel>
also we'd need to recompute some trig functions at every frame... the PFPU can do it, but it's a bit of work
<wpwrak>
for clipping, i guess the image could just be placed in a rectangle with a wide enough black border ?
<lekernel>
not optimal because the TMU will scan that black border, but you can try ...
<lekernel>
I try to avoid stuff that could drop the fps too much
<wpwrak>
hmm yes. everything has a cost ...
<lekernel>
the proper way to do it is to use the triangle as the TMU rendering primitive but
<lekernel>
1. it is surprisingly difficult to fill all possible configurations of a triangle without bugs
<lekernel>
2. without a Z-buffer, you have problems on the overlapping triangle borders when alpha blending is enabled
<lekernel>
3. #1 not only wastes my time, but it also means that FPGA resources are spent on implementing various corner cases
<wpwrak>
1) indeed. numerical geometry is full of surprises :)
<wpwrak>
2) or more corner cases
<lekernel>
#2 is easily solved for rectangles: they are defined as the surface for which x(n) <= x < x(n+1) & y(n) <= y < y(n+1) - so there is never an overlapping pixel on a rectangle tesselation
<lekernel>
the case for triangles is messy
<lekernel>
I guess GPUs solve it with the Z-buffer
<wpwrak>
for triangles, you could do antialiasing. that way, the sum would also be 1. but yes, lots of work
<lekernel>
you can still have precision problems, no?
<lekernel>
at the end you need to encode the color in the original format... which means rounding
<wpwrak>
yes, but should be small
<lekernel>
maybe in 10:10:10 it will be small, but I expect this to be a major problem in 5:6:5
<wpwrak>
hmm, maybe. the steps are kinda large, so even being off by one epsilon could stick out
<lekernel>
I'm not even sure that antialiasing would solve it
<lekernel>
if two triangles share a common edge, it will simply draw that edge twice
<lekernel>
it would only work if edges are drawn at alpha/2 transparency
<lekernel>
which could be a good idea, btw
<lekernel>
but there should be a way to make sure that only shared edges are drawn at alpha/2, so the TMU can be used for "exact" blitting
<lekernel>
which would be useful e.g. in GUI acceleration
<lekernel>
lots of work...
<wpwrak>
you wouldn't alpha-draw the edge per se but the fraction of the triangle area that coincides with the pixel area
<lekernel>
and actually, if we know shared edges in advance, we can simply draw one with the normal alpha and omit the others
<wpwrak>
good luck with the corners, though :)
<wpwrak>
yes, maybe there are some heuristics that yield good results without doing all that much work
<lekernel>
doing all this stuff in verilog is also messy
<lekernel>
http://orcc.sourceforge.net/ could be interesting... so far I've been turned down by their focus on java
<wpwrak>
i'm kinda dubious about any great unification languages
<wpwrak>
the svn reminder doesn't sound too outrageous, though
<lekernel>
nah but I've tried to use academic tools in the past, and they're full of dead code, syntax errors, old binaries laying around (and sometimes being subtly used in place of the syntax-error-ridden code), etc.
<lekernel>
so I pay much attention to such warning signs now
<lekernel>
also, why are they using svn and not git? only bad programmers use svn/cvs
wpwrak joined #milkymist
<wpwrak>
depends on the age of the project and the structure
<wpwrak>
the main problem of svn is its slowness. but if you don't search around a lot and people's activities don't overlap much, it's quite bearable
antgreen joined #milkymist
<lekernel>
I don't plan to use it as a unified language btw... just as a high level tool to generate VHDL by the metric ton for complicated hardware accelerators :)
<lekernel>
I think there are good ideas in the design, even if the implementation might suck (as I can judge by those warning signs)
<whitequark>
not sure that I get what the "one high-level design" is, through
wolfspraul joined #milkymist
<wpwrak>
lekernel: btw, an idea for texture mapping: i wonder if you could get away - in a useful set of cases - with treating pixels as circles. that way, the overlaps would have fewer parameters and you may be able to use optimized special-case operations for them.
<GitHub160>
[milkymist] sbourdeauducq pushed 1 new commit to master: http://git.io/SKTEuw
<GitHub160>
[milkymist/master] fpvm: new fpvm_set_bind_callback API - Sebastien Bourdeauducq
<GitHub54>
[milkymist] sbourdeauducq pushed 1 new commit to master: http://git.io/mZxNww
<lekernel>
ok, now we can crank up midi variables, dmx channels, etc.
<wpwrak>
midiN += 100 ;-) let's see what your patch does ...
<wpwrak>
but the total number of pre-defined variables, whether used or nor, is still limited to 128, right ?
<lekernel>
only used variables are limited to 128
<lekernel>
that's what the new register allocator does :)
<lekernel>
(actually, less than that because you need space for constants and internal variables. but much better than the previous allocator which preallocated everything)
<GitHub162>
[flickernoise] sbourdeauducq pushed 1 new commit to master: http://git.io/8NoEOQ
<GitHub162>
[flickernoise/master] New patch - Sebastien Bourdeauducq
<wpwrak>
hmm, need to study this later :) afk for a few hours ... bureaucracy day ...
<GitHub194>
[milkymist] sbourdeauducq pushed 1 new commit to master: http://git.io/D4dknA
<GitHub194>
[milkymist/master] fpvm: support source-only binding - Sebastien Bourdeauducq
<GitHub51>
[flickernoise] sbourdeauducq pushed 1 new commit to master: http://git.io/LSa8WA
<GitHub51>
[flickernoise/master] compiler: do not bind internal variables - Sebastien Bourdeauducq
<lekernel>
of course, the RTEMS FTPD "root" option has bugs ...
<lekernel>
I already fixed two major bugs in this crap ftpd, seems there's going to be a third one ...