<lekernel>
but unless you're tracking down some USB bug that makes your keyboard not work at all, you do not need to touch softusb-input to implement keymaps
<xiangfu>
it have two interfaces, one for keyboard, one for mouse.
<xiangfu>
when I plug this device to m1. the keyboard works fine. but mouse not working.
<lekernel>
phew. messy...
<xiangfu>
so I guess it's easy for make the keyboard and mouse both working in m1.
<lekernel>
no. USB is an horrible time sink. can you get the keymaps to work first? :)
<xiangfu>
:) yes. I will get the French keyboard tomorrow. then I will work on that.
<lekernel>
have you understood how input.c works?
<lekernel>
btw, all those two interfaces mean is that you have two endpoints
<xiangfu>
is this "make_usb_token(0x69, 0x081, usb_buffer);" means get data from endpoints "0x81" ?
<lekernel>
so unless there is again some trap in that imbecilic USB standard, all you should need to do is 1) parse all interface descriptors, and recognize those which are keyboard/mouse (there is already code for that) 2) store the (device type,USB port,endpoint) tuples and add them to a poll list
<lekernel>
hm, I don't remember
<lekernel>
but really you are probably going to spend a lot of time if you dive into that
<lekernel>
just to get a minority case (keyboard with integrated mouse) to work
<juliam_c>
is this channel only to ask if i adquire your products???
<xiangfu>
for now the software-usb only read '0x81  EP 1 IN", I think I just need add read '0x82  EP 2 IN' to poll(), then the (keyboard with integrated mouse) will working, right?  (just want to understand, if you say it's hard, I think I will just give up :)
<lekernel>
xiangfu: no, because then you'll have the case where the endpoint numbers for the keyboard and mouse are different from that particular keyboard you have
<lekernel>
so you need to go through the interface parsing
<lekernel>
told you... USB = mess
<lekernel>
all that just to get a stupid stream of keystrokes and mouse moves
<lekernel>
overengineering at its best
<lekernel>
juliam_c: no, but as far as I'm concerned it helps if people are doing an interesting project. porting MM SoC to some third party devel board doesn't really motivates me.
<juliam_c>
ok thank you for your answer.
<kristianpaul>
juliam_c: if you have a MM1 yes, you can ask for support, but as topic said, it is also Milkymist SoC development channel :-)
<lestat>
hi
<xiangfu>
lestat: hi
<kristianpaul>
hola :)
<CIA-48>
flickernoise: Xiangfu Liu master * r68aea67 / src/performance.c : display patch author and name when Simple Performance - http://bit.ly/jRjKE6
<lekernel>
xiangfu: if you really want to implement this, we need to find a way to disable it, and probably disable it by default
<xiangfu>
lekernel: oh. yes.
<lekernel>
honestly, it's just going to be annoying when used live
<xiangfu>
yes. but I even want it display something like 'Milkymist' for people know what they are using. :)
<xiangfu>
lekernel: yes. VJs will not like this 'message' for sure.
<wolfspraul>
lekernel: in which way would a 'pro user' or VJ typically use the m1?
<wolfspraul>
will he pick some patches in advance?
<wolfspraul>
how many?
<wolfspraul>
does he want to iterate over them, or stay with one?
<lekernel>
yeah, but we need to get the defaults right
<lekernel>
ok, so for this 'patch sampling' application
<lekernel>
which displays the patch name
<wolfspraul>
the default should be for the technically unsuspecting end user, so something works out of the box
<wolfspraul>
but of course I fully agree that it's annoying for a VJ or any sort of controlled performance
<lekernel>
can we just add a 3rd button on the control panel, which starts simple mode but with patch titles displayed?
<lekernel>
and have them disabled in all other cases
<wolfspraul>
wait too much and too fast for me. can you tell me how you think a VJ will use m1?
<wolfspraul>
1) pick 1 patch, or multiple?
<lekernel>
multiple
<wolfspraul>
2) go through the patches in the performance? in which way? random, or planned sequence?
<wolfspraul>
ok but he knows in advance which patches he likes
<lekernel>
yeah
<wolfspraul>
he writes down the names somewhere?
<wolfspraul>
or he makes one of those group/list files (I remember some feature like that...)
<lekernel>
but if we want an 'out of the box' experience, we might as well have the name display disabled by default
<lekernel>
xiangfu: performance.c:326:3: warning: implicit declaration of function 'osd_event'
<wolfspraul>
if I pick patches in advance, most likely I will not want to see the name of the patch or author
<lekernel>
what I am proposing is:
<wolfspraul>
but I may just click through patches visually to even decide which ones I like
<wolfspraul>
in which case I will want to see the names, so I can write down which ones I liked
<wolfspraul>
I need to look at some more features we have already, like lists, and also the commands in patches
<wolfspraul>
still learning...
<lekernel>
1) simple performance mode, i.e. all patches found in online repository and switch with push button, without patch names displayed, which starts out of the box by default
<lekernel>
also with a button on control panel
<lekernel>
2) simple performance mode with patch names displayed, which can be started with a click in the control panel
<lekernel>
3) normal performance mode with a pre-selection of patches
<wolfspraul>
sounds good
<xiangfu>
sounds good
<wolfspraul>
we will learn more details later and can finetune
<lekernel>
I didn't plan #2 initially, but apparently you and xiangfu want it
<lekernel>
#1 and #3 are working
<wolfspraul>
but for that I need to understand the real use cases better first... so right now I cannot even seriously propose an improvement over what you suggested.
<wolfspraul>
lekernel: no, not really. I really don't want to push you to implement features. I don't have full enough picture of use cases yet (though I'm definitely becoming more and more clear :-))
<wolfspraul>
so keep your great focus, and don't implement #2, and save some time
<wolfspraul>
and xiangfu and I are learning...
<lekernel>
xiangfu: void start_performance(bool simple) -> void start_performance(int mode), with 3 modes: simple, simple with patch names, normal
<xiangfu>
lekernel: ok.
<xiangfu>
lekernel: will fix the waring. sorry for careless.
<wolfspraul>
xiangfu: if lekernel thinks it's not good, we don't do it
<lekernel>
well, it still has some use
<wolfspraul>
there is no reason to rush all sorts of small features into the product now, it's more important to have one strong consistent end user feeling
<lekernel>
if you want to sample patches and note down patch names...
<xiangfu>
and 'screenshot' :)
<wolfspraul>
yes, that's what I had in mind, and hence my questions above
<lekernel>
wolfspraul: you can also use the patch editor to load and run a specific patch
<wolfspraul>
I was wondering how the VJ actually knows which patch is which, even to plan his performance.
<wolfspraul>
yes, but it's tedious
<lekernel>
yeah
<wolfspraul>
clicking through and writing down what one likes sounds like 5 times easier
<lekernel>
so we can have that 'patch name display' feature, but disable it by default
<wolfspraul>
I even had the problem myself. there are some patches I like, but I can never find them again :-)
<lekernel>
xiangfu: wait
<lekernel>
maybe we can do in another way
<xiangfu>
(reading the irc ...)
<lekernel>
what about displaying the patch name, no matter what, when e.g. F3 is pressed on the keyboard?
<lekernel>
so you can find the name of that patch you like and is currently running, at any time
<wolfspraul>
sounds like a good idea. need to think more but sure - good!
<lekernel>
should be easy to and doesn't clutter the control panel with even more buttons
<wolfspraul>
lekernel: oh, the other thing I had in mind was m1 as a tool to fill the empty space between talks at conferences
<lekernel>
that was rejon's idea, no?
<wolfspraul>
totally different use-case, I thought about it because of LGM
<wolfspraul>
so in that use case, you actually want to go to the next patch automatically, after let's say 2 minutes or 5 minutes
<wolfspraul>
and then you want to use the chance for some promotion, and display "Milkymist - patch_name by patch_author" for a good 10 seconds or so, after switching to the next one
<wolfspraul>
but of course that's a different use case
<wolfspraul>
we need to be careful that the product is not hard/un-intuitive for all use cases in the end
<wolfspraul>
in that case m1 is more running only to provide some background entertainment, and people will look at the display or not
<wolfspraul>
or glance at it briefly, then continue chatting, etc.
<wolfspraul>
so you want to use that chance that they see the name 'Milkymist' :-)
<lekernel>
wolfspraul: use the twitter wall
<lekernel>
not only they would see it, but also tweet it to get their messages on it :-)
<wolfspraul>
ok I need to try this all out in detail
<wolfspraul>
just thinking about some use cases now
<lekernel>
anyway. for the patch title, display it on F3 (or another key) press.
<wolfspraul>
there is still the case without Ethernet
<wolfspraul>
yes, good [f3]
<lekernel>
atm one of the features that I think has higher importance than those is localization
<lekernel>
I can't approach a French store with something entirely in English, for example
<lekernel>
maybe F1..
<lekernel>
then we can have:
<lekernel>
F1 -> display patch title immediately
<lekernel>
F2 -> enable/disable patch title display at patch switch
<lekernel>
F3 -> enable/disable automatic patch switch after delay
<lekernel>
F2 and F3 only active in simple performance mode, F1 active all the time
<lekernel>
what about that?
<wolfspraul>
wow a lot. I can only give feedback after I use this for some time. but sure, sounds good!
<lekernel>
well you ask for it, now you get it
<lekernel>
it's not that much actually
<xiangfu>
there is a 'automatic patch switch' ?  how it work?
<lekernel>
no, there isn't
<lekernel>
but wolfspraul wants one
<xiangfu>
ok
<xiangfu>
then understnad.
<xiangfu>
I will finish the 'F1 -> display patch title immediately' first, then create a snapshots images :)
<wpwrak>
lekernel: however marvelous your technology, you can't beat that round oscilloscope ;-)
<wpwrak>
lekernel: oh, about displaying stuff. if you run out of buttons, you could also display things only while the button that triggered the switch is being pushed. e.g., on push, switch and show the OSD, on release, clear the OSD.
<lekernel>
ah yeah, I've heard of those guys years ago through the /tmp/lab
<azonenberg>
lekernel: I won't be om Europe any time soon, sorry
<azonenberg>
s/om/in
<lekernel>
ok. was just in case :)
<azonenberg>
But i'll be sure to keep you guys updated on my progress
<azonenberg>
I ran a test this weekend of my photoresist (thinned with acetone to make it less viscous) spin-coated on silicon
<azonenberg>
Worked beautifully at 60um feature sizes, the 15um run i thinned it a little too much but most of it still resolved
<azonenberg>
I didnt try the 5um process though
<azonenberg>
i dont have any polished wafers
<azonenberg>
and unpolished lapped finish is so rough that 5um features won't resolve
<azonenberg>
So the next step is to wait until payday and buy a batch of wafers :)
<azonenberg>
i'm looking at getting two <100> SSP 100mm wafers for surface micromachining work, and ten 1cm x 1cm square <110> dies
<azonenberg>
For reasons unknown, <110> is quite a bit more expensive
<roh>
azonenberg: what kind of equipment do you have and use?
<azonenberg>
roh: A hack job lol
<roh>
hrhr
<azonenberg>
Spin coater is made from an electric drill, sanding wheel, and a 2x4
<roh>
azonenberg: so you are basically working on semicond. manuf. equipment, redneck-style, homebrew
<roh>
?
<lekernel>
roh: yes ... you should check the irc log from a couple of weeks ago :-)
<azonenberg>
roh: mask aligner is a microscope plus some electrical tape
<azonenberg>
my exposure lamp is a AA maglite
<azonenberg>
though i'm getting a UV led next payday
<wpwrak>
azonenberg: are you a son of McGuyver ? :)
<azonenberg>
wpwrak: Lol, no
<azonenberg>
Nor am i jeri ellsworth's brother
<azonenberg>
Just another random geek
<lekernel>
well, in some ways your work is better than jeri's. starting with having some documentation and caring about content licenses.
<azonenberg>
lekernel: Content licenses?
<azonenberg>
When did i ever mention that
<azonenberg>
Or she, for that matter
<roh>
azonenberg: nice
<lekernel>
didn't you say you wanted your stuff to be under creative commons? or bsd?
<azonenberg>
lekernel: Ah, yes i did
<roh>
i wonder what we could do with some used equipment and people like you and jeri
<azonenberg>
Probably CC-BY for the documentation and BSD for code
<azonenberg>
mask art is TBD as i dont know of any existing FOSS licenses for mask work
<azonenberg>
i'd need to think of what will fit best
<lekernel>
Jeri never mentioned that - actually, she doesn't care the slightest bit about open source
<azonenberg>
cc, treating it as art? BSD, treating the cad fils as code?
<azonenberg>
s/fils/files
<azonenberg>
roh: I want to build myself a full fab eventually using nice equipment but for now i'm going "redneck style" as you put it
<azonenberg>
i cant afford a SEM or commercial mask aligner etc lol
<azonenberg>
But i sure can afford a bit of duct tape :P
<roh>
i see. will for sure give interresting results.. was just already thinking a step ahead how to make stuff more repeatable and reliable
<roh>
maybe some stuff is more simple than it seems and we only need a few precisely manufactured parts.
<azonenberg>
That's my thought as well
<azonenberg>
Current goal is a MEMS comb drive end of the calendar year
<roh>
i got a lasercutter and a cnc mill around. werner has a mill too. and there are lasercutters and simple mills in lots of hackspaces. would be nice to have some way to replicate your results
<azonenberg>
End of summer i want bulk micromachining worked out
<azonenberg>
i.e. build the silicon mechanical structure
<lekernel>
:))
<roh>
wow. tight plan.
<azonenberg>
then i'm giving myself till the end of the calendar year to build a DC sputtering system or thermal evaporation rig
<azonenberg>
for metal deposition
<lekernel>
why not RF?
<lekernel>
once you got that far, building a RF supply doesn't look so hard :-)
<roh>
RF?
<lekernel>
yeah, I've read it makes some aspects of the sputtering easier/better
<lekernel>
"The use of a radio frequency (RF) generator is essential to maintain the discharge and to avoid charge build-up when sputtering insulating materials such as PZT."
<azonenberg>
lekernel: I'm considering RF for hardware rev 2
<wpwrak>
lekernel: so, how much optimizing will MM1 need to fit in a chip made with a 5 um DIY process ? ;-)
<azonenberg>
wpwrak: Lol
<azonenberg>
Quite a bit
<azonenberg>
Bigger question, will i be below 5um by then? :P
<azonenberg>
My roadmap already goes down to 1-2um
<azonenberg>
The problem is scaling up to bigger die sizes
<azonenberg>
i.e. >100 \lambda across
<wpwrak>
azonenberg: 1-2 um .. so if you keep the pace, it'll be 200 nm by 2012, 40 nm by 2013, and 8 m, by 2014 :)
<wpwrak>
err, 8 nm
<azonenberg>
wpwrak: Lol
<azonenberg>
500nm is the smallest i expect will be even possible with my current process
<azonenberg>
Since that's the smallest thing i've even been able to *see* with these optics
<azonenberg>
But realistically, since my current focus is MEMS and not CMOS
<azonenberg>
How much smaller do you need?
<wpwrak>
the 386dx was made with a 1 um process. 275 ktransistors.
<azonenberg>
Exactly
<azonenberg>
So for hobbyists, the current scale (or a little further) is probably adequate
<azonenberg>
The big thing is expanding die sizes
<wpwrak>
due to lens distortions ?
<azonenberg>
No, field of view
<azonenberg>
I cannot make the FOV bigger than it is now with the current process, so i'll need to design a scanning system
<azonenberg>
using two motorized stages (one for mask and one for die)
<azonenberg>
keeping those in sync +/- 1um for a 2-5um process
<azonenberg>
over what could be a pretty long exposure
<azonenberg>
The other fab technique i'm considering is more involved but may give better results in the long term
<azonenberg>
Laser direct write onto metalized microscope slides to make metal-on-glass masks
<azonenberg>
Then contact lithography 1:1 using those
<wpwrak>
1 um mechanics is tricky. an easier approach could be to do basically multi-chip on the same substrate. do high-density blocks and connect them with low-density links. that way, you can afford more mechanical tolerance.
<azonenberg>
Yes, i considered that too
<azonenberg>
So step multiple exposures across
<azonenberg>
using big fat bond pads to connect
<wpwrak>
yeah
<wpwrak>
"laser direct" also sounds interesting :)
<azonenberg>
Blu-ray sled on a perpendicular axis
<azonenberg>
direct write onto the mask
<azonenberg>
You can either do 1:1
<azonenberg>
Or, say, use the laser to make a 25um scale mask
<azonenberg>
then shrink 10x using the projection system to get 2.5um
<wpwrak>
what's the focus range of such a blue-ray laser ? maybe you could also spin the laser around and do the high-resolution work via time
<wpwrak>
e.g., a pendulum. laser could be fixed or the pendulum. then synchronize with the pendulum's movement and modulate the beam accordingly. that might give you pretty good resolution along one axis.
<wpwrak>
maybe the sled can do the other axis :)
<wpwrak>
(pendulum) or if the chip is the moving part, just spin it. mechanically probably even easier.
<azonenberg>
Nope, i dont think so
<azonenberg>
The sled already has one axis
<azonenberg>
i just need a single-axis linear stage
<azonenberg>
Focus range is pretty short
<azonenberg>
good focus will need very good planarity i think
<wpwrak>
hmm, then spinning may not be so good. what's the track-to-track spacing in BR ?
<azonenberg>
no idea
<azonenberg>
I havent looked into it in much depth yet
<azonenberg>
projection was the rev1 option because it was so much easier to build
<wpwrak>
a BR x/y laser plotter ought to be fun :) well, maybe start with DVD. cheaper failed experiments ;-)
<azonenberg>
Well, here's the issue
<azonenberg>
DVD is infrared
<azonenberg>
bluray is 405nm
<azonenberg>
Which is right in the peak sensitivity range of most photoresists
<azonenberg>
I'm not patterning by ablation
<azonenberg>
that needs way too much power
<wpwrak>
ah, i see. so it's not only for the finer structures
<azonenberg>
this is photochemical
<azonenberg>
The photoresist needs ~200 mJ / cm^2
<azonenberg>
So even a 1 mW laser is plenty
<azonenberg>
200 sec for a cm^2 die
<azonenberg>
in fact, something more powerful like a bluray will probably have to be fired in few-ns pulses to keep it from dumping too much power and causing heat damage to the mask lol
<wpwrak>
mount a big fan on top of it :)
<azonenberg>
Still, localized heating
<azonenberg>
The concern is thermal gradients
<azonenberg>
Uneven expansion
<azonenberg>
and the mask not being the same shape after it cools off
<azonenberg>
i'm not using super-expensive ultra-low-thermal-expansion glass for the mask blanks :P
<wpwrak>
hmm yes. so it's ns pulses then.
<kristianpaul>
azonenberg: you have a blog/wiki/mail-list or something  to follow your work?