#milkymist IRC log for Saturday, 2012-05-26

mwallenice, ehsm on heise :)00:14
lekernelwolfspraul: so, what do you think about a kintex-7 + ddr3 board?14:28
lekernelI was thinking about buying a KC705 http://www.xilinx.com/products/boards-and-kits/EK-K7-KC705-G.htm14:28
lekernelbut it only takes DDR3 modules, which are a pain in the ass as I already mentioned14:28
lekernelI want to remove the non-distinctive features of the M1 and add good distinctive ones14:32
lekernelbasically, the new board should have FPGA, DDR3, Flash (SPI or parallel NOR), 3 or 4 HDMI video in/outs, Ethernet (still good for debugging and updates), reactable-style interface with built-in LCD, some expansion ports - and nothing else (that's already a lot)14:34
Action: kristianpaul likes the reactable-style interface14:48
wolfspraulsure, nice14:50
wolfspraulthe kintex-7 chip will probably be quite expensive, but we can look at that later and then move to artix-7 if that turns out to have all the same features we need and want at a lower price?14:51
wolfspraulflash I personally would prefer SPI now14:52
wolfsprauldigital video-in and out is great14:52
wolfspraulwhat are 'expansion' ports?14:52
lekerneljust the same sort of connector that we have now14:52
lekerneldirectly routed to fpga14:52
wolfspraulyou remove what?14:53
wolfspraulanalog video in14:53
wolfsprauleven usb?14:53
lekernelyes, especially usb14:53
lekernelit's a pain and people take it for granted14:53
wolfspraulwe can continue to develop it on the m114:54
wolfspraulwe absolutely need to watch for continuity between the m1 and this new board14:54
wolfspraul'continuity' in the sense of 1 unified source tree primarily, binary compatibility is another matter14:54
wolfspraulsure why not, it sounds like that new board would be a very different angle and allow m1 to continue to exist in parallel, which is good14:55
lekernelas far as I'm concerned, I don't feel like developing stuff specifically for the M1 anymore. but I can merge M1 support patches and generally help other people with backporting stuff to the M1.14:55
kristianpaulwait, so video in will come as hdmi too?14:56
lekernelyeah, we should have bidirectional HDMI ports14:57
kristianpaulor no more this feature about mix video with effects etc?14:57
wolfspraulthe goal would be that nothing much needs to be 'specifically developed for m1'14:58
wolfspraulwhat is the migen plan actually?14:58
wolfspraulis it realistic that it will fully work (on m1), soonish/later/never?14:58
lekernelit works on M1 today14:59
wolfspraulI mean we can push out an update that was built with migen in the background and people won't complain about missing things :-)14:59
lekernelwell, then you need to port USB, MIDI, DMX, ...15:00
kristianpaulUSB at least ;-)15:00
wolfspraulthat sounds like no migen release is planned for m115:00
kristianpaulor internal usb15:00
lekernelhope that you have enough memory bandwidth to run the new software15:01
kristianpaulmigen is been developed for m1 right now? no?15:01
wolfspraulwho hopes? don't understand15:01
lekernelalso you need to redesign the UI, which won't be mouse-based anymore15:01
kristianpaulah wait, migen for m1 will not improve memory speed?15:02
lekernelthe backport will be quite some of work.15:02
lekernelkristianpaul: it does. but ddr3 will improve it even more.15:02
wolfspraulwe need a dose of honesty and realism here15:02
wolfspraulI think there will be no fully functioning migen for m1, ever15:03
wolfspraulI just say 'fully functioning' instead of 'working' now :-)15:03
lekernelbtw migen != milkymist-ng15:03
wolfspraultell us more15:03
lekernelmigen is the new tool to build the milkymist-ng soc15:03
lekernelwell, there can be, but as always - someone has to do it15:04
wolfspraulif you are not planning to do it, it will never happen15:04
wolfspraulwhich is ok, we just need to be open about it, imho15:04
lekernelhe. what do you want me to do? keep agitating that M1 no one cares about? or go forward, improve the system performance a lot, design a beautiful and much more usable tangible interface, and the software that goes with it?15:06
wolfspraulI don't feel I should tell you what you 'should' do, milkymist is doing quite well imo15:07
wolfspraulyou did a great job15:07
wolfspraulpeople are learning about the soc, digital design, fpgas, etc.15:07
wolfspraulthe big product uptake has not happened, but at least from the things I learned in the last 2 years, I am not surprised about that15:07
wolfspraulmost of the things I learned is about what does *not* work :-)15:07
lekernelso. backporting next-MM features into the M1 sounds like a great learning project. and I would support such initiatives.15:07
wolfspraulsure sure15:08
wolfspraulbut that's just meaningless blurb for 'will not happen'15:08
wolfspraulpeople are better off following the new thing then15:08
wolfspraulof course15:08
wolfspraulI like the new design/board idea15:08
wolfspraulthrow out all the old stuff, focus on new, carry forward the good things15:08
wolfspraulfor m1 that means something like 'milkymist legacy' or so15:09
wolfspraulno idea right now how new products can come out of it, more or less abandoned on the soc level15:09
wolfspraulI don't see a big problem if you 'move on' from the m1 soc15:10
lekernelI did the hard part already15:10
lekernelthe DDR is working15:10
lekernel(on the M1)15:10
wolfspraulthat's besides the point because nobody will ever use it15:10
wolfspraulin reality, not from what you think someone 'might' or 'should' do15:11
wolfspraulnobody will15:11
wpwrakif we abandon milkymist, does it even make sense to produce m1r4 then ?15:11
wolfspraulbut anyway, I agree with your thinking15:11
wolfspraul'abandon milkymist' goes a little far15:11
wolfspraulwe are overwhelmed in actually getting the new migen/-ng stuff fully "backported" to m115:12
wpwrakwell, it still has numerous issues that could be fixed without having to move to new hardware15:12
wolfspraulnot that much surprised about that15:12
wolfsprauland to sebastien it appears better to focus on new things only, which I can understand15:12
wpwrakand m1r4 will need even new development, e.g., for dvi15:12
wolfspraulthat would overlap with the new focus on digital video in and out15:12
lekernelthat DVI development will be useful for the next product too15:12
wpwrakas i understand things, migen is a prerequisite for faster memory15:12
wolfspraulI don't think that migen thing will happen on m115:12
wolfspraulnot fully15:12
wpwrakwithout migen for m1r4, dvi will therefore be useless15:12
wolfspraulthere is just not enough momentum/motivation15:13
kristianpauli'm worried more about software support right now than hardware improvements at all (besides memory speed)15:13
lekernelwpwrak: at least, you'll have a framebuffer15:13
wolfspraulI am just realistic - unless sebastien finishes the -ng support on m1 100%, it will not happen15:13
wolfspraulwhatever empty words of 'nice entry-level task' we wrap around that15:13
lekernelwith high resolution and 10:10:10 color depth15:13
lekernelrunning on the new memory infrastructure15:13
wpwrakkristianpaul: memory speed also gives us issues like the "fade to green" effect. that limits the device's abilities quite a bit15:14
wpwraklekernel: (new memory infrastructure) that's the new device ? or milkymist ?15:14
lekernelthat's M115:14
wolfspraulin terms of 'productization', I will probably stay on m1 and see how I can get some incremental improvements going there15:14
lekernelthe infrastructure that I'm prototyping today on the M1 will be on the next device - only with DDR3 and more chips15:15
wolfspraulif we zoom out, one could say that we totally overwhelmed ourselves in making the features on m1 actually work good15:15
wolfspraulso what we learned from that is to dramatically cut features by 90% or more15:15
wolfsprauland make a new board15:15
wpwraklekernel: so you plan on making migen suitable for replacing the existing gateware ?15:15
wpwraklekernel: (on M1)15:15
wolfspraulwhile we leave the old, overwhelming, design in the background hoping that it will slowly emerge15:15
lekernelwpwrak: to a certain extent, yes. but I will not develop features that won't be present at all on the next product.15:16
lekernelthough if someone does it, I won't refuse the patches15:16
wolfspraulsuch as midi, dmx, usb, infrared, ... :-)15:16
wolfspraulso basically m1 is abandoned, from that perspective15:16
wolfspraulbut I agree we have to CUT CUT CUT features15:17
wpwraka rather disappointing development15:17
wpwrakso all the work we put into m1r4 was wasted15:17
wolfspraulI don't see it like that15:17
wpwraklekernel: you have an interesting way of motivating people ;-)15:17
wolfspraulmaybe my expectations already were different for months :-)15:17
wolfspraulm1 is a lesson in overpromising15:18
wolfspraulby a factor of 100, at least15:18
lekernelit's not even hard to reuse the legacy verilog with migen15:18
wolfsprauluntil today I am sure I can easily find keyboard & mice that won't work15:18
wolfsprauldon't even get me started about any of the other stuff15:18
lekernelhaving USB with the current code on milkymist-ng on M1 can probably be done in a few hours by someone with no prior migen experience15:19
lekerneland same for most of the cores, except the few ones that use DMA direct to the DRAM because the memory system is very different there15:20
wolfspraulyou are not planning to do it15:20
wolfspraulyou should say so15:20
lekernelI already have15:20
wolfsprauland from what I learned over the last 2 years, I take a bet that that means "it will not happen"15:20
wolfspraulI was replying to the usb comment15:20
wpwrakif it's so easy, it would probably more efficient for you to do it than to argue about why you won't do it ;)15:21
lekernelyes. this goes under the more general "features that will not be present at all on the next product"15:21
wolfspraulyou don't need to convince me anyway, since I am forming my own opinion15:21
wolfspraulI agree to abandon m1 from your perspective and focus on a new board as outlined above15:21
wolfspraulCUT features15:21
wolfsprauland we keep m1 around and 'supported' hoping that it can slowly serve as a basis from which to build future product, and from which to *forward-port* to future milkymist-based products as well15:22
lekernelthough actually, for USB, we might actually reintroduce it at some point15:22
wolfsprauleven thouhg that is outside of the scope of your work15:22
lekernelit's (unfortunately) too well spread that we can ignore it so easily15:22
wolfspraulI like the new board15:22
wolfspraul(the idea)15:22
wolfspraulm1 is essentially a devel board for 10-20 people15:22
wolfspraulthe attempt to productize it failed15:23
wolfsprauland that new board will also be a devel board for a few people15:23
lekernelso USB developments on M1 still make sense, I think. in the long term.15:23
wolfsprauland we need those new features anyway, -7, ddr3, digital video in and out15:23
wolfspraulso if you start with that now, it goes in parallel with the more tedious stuff we do on m1, and overall we accelerate the milkymist platform15:24
wolfspraulthat's my thinking15:24
wolfspraulit's not like we don't have another few hundred (or thousand) bugs on m1 left :-)15:24
wpwraki see putting linux on it as a way to solve many of the system software issues. you just need to port the drivers that talk to our unique hardware, and redesign usb a bit. once that is done, a lot of the scary features don't need cutting anymore. at least not because they're scary.15:24
wolfspraul'bugs' as in "things regular people would like to do"15:24
wolfspraulSebastien will see linux along the lines of usb15:24
wolfspraulbig old legacy stuff15:24
wolfspraulI think sebastien should charge ahead with the new board15:25
wolfspraulthat plays to his strengths15:25
wolfspraulwe have to catch up with the base and think about what products can be formed out of all this15:25
wpwraki see a disconnect regarding migen. at least the pixel size and all that entails seems essential for m1-as-a-vj-system.15:26
wolfspraulI will not abandon m1. I have learnt a ton through and with it over the years, and I know users want this and want *more* out of it, which unfortunately we cannot deliver now.15:26
wolfspraulyes but I think sebastien will not 'finish' migen or -ng for m115:26
wolfspraulit's too much work15:27
lekernelwpwrak: what's "pixel size"?15:27
wpwrakwith migen on the m1, without a regression in functionality, i'd see much less of a problem in maintaining it without sebastien15:27
lekernelwolfspraul: actually you will have VGA/DVI working15:27
wolfspraulso we have some half-finished thing that 'works' but of course no update can be pushed out etc.15:27
wolfspraullekernel: I need a coherent update15:27
wpwraklekernel: bits per pixel15:27
wolfspraulif we have that - great15:27
wolfsprauleven if the build/synthesis process is messy, doesn't matter15:27
wolfspraulbut until we don't have that, it's not there15:27
lekernelwolfspraul: and pfpu/tmu hw acceleration15:27
wolfspraulwe can't tell our users that m1 is being reduced from a product to a devel board and after the next update they need to learn C, or worse15:28
lekernelaudio and usb can be backported easily by just linking the legacy verilog, and with that you have a basic rendering system15:28
wolfspraulso either there are no regressions, or it's not an 'update'15:28
wpwrak"new patch language: VHDL" ;-)15:28
wolfspraulyou plan to do that?15:28
lekernelvideo-in is a bit more trouble and needs some architecture understanding15:28
kristianpaulwpwrak: ha15:28
wolfspraulwhen you say 'easily' that sometimes means you think someone else can do it easily :-)15:28
wolfspraulI'm not pushing you to do it btw15:29
wolfspraulI already explained above that I think you play to your strength by focusing on that new board15:29
wolfsprauland we know you will review any m1-related patches in good faith15:29
wolfspraulonly that there will be no such patches, or very few15:29
wolfspraulbut what can you do15:29
wolfspraulwe cannot get stuck there15:29
lekerneland finally, pixel depth... not sure how to fix that one. either change the migen descriptions to go back to 16bpp or upgrade the software to 3215:29
wolfspraultrust me - if Sebastien is not *finishing* those things, they won't happen15:30
wolfspraulwhich is ok, we just need to be open about it15:30
wolfspraulbecause even if he would sit down and do all that - what is gained?15:30
wpwraklekernel: i thought migen had the increased pixel depth already ?15:30
wolfspraulit's better to focus on the future15:30
lekernelwpwrak: there's no video stuff yet15:31
wpwraklekernel: the dependency chain i see is pixel depth || dvi -> memory bw -> migen15:31
lekernelbut I think the M1 can definitely render in 640x480 at 32bpp with the -ng memory controller15:32
wpwrakwolfspraul: i'm not against focusing on the future. but if we want to continue selling m1, we still need to turn it into a more rounded product. and video effect quality is pretty important for this.15:32
wolfspraulwho will deliver this update?15:32
wolfspraulwe have tried to sell a lot of hot air with m1 in the past15:33
wolfspraulfor the things I learned, I will not continue to do that15:33
wolfspraulso one by one as I learn what does *not* work, I stop trying to use that to sell, of course15:33
wolfspraulbecause it cannot work15:33
wolfspraulif Sebastien does not plan to finish this work and update it all the way to a 'zero regression' state, then it will not happen15:33
wolfspraulthat's a pretty binary thing15:33
wolfsprauleither the actual update (for a user) happens, or not15:34
wolfsprauland time is ticking15:34
wolfspraulthat's not wishful thinking15:34
wolfspraulnot a 'plan'15:34
wolfspraulor 'easy'15:34
wolfspraulor "just a few"15:34
wolfspraulor any of that15:34
wolfspraulthe update is either there or not15:34
wolfspraulif not - ok15:34
lekernelnot from me15:34
lekernelbut as a migen/milkymist-ng development board, the M1 is still there.15:35
wpwrakit's a question of efficiency. sebastien knows migen best. and probably still makes changes to it, when he hits difficulties when integration/porting features. so he's in the best position to port things like usb as well.15:36
wolfspraulI doubt that will happen15:36
lekernelwith (at least coming from me) a basic SoC working, i.e. cpu, memory, framebuffer15:36
wolfspraulsebastien will move m1 to a "I review patches when I get them" mode15:36
wpwrakonce we have a basis that can actually run the existing stuff, taking care for maintenance (in a wide sense) sounds a lot more feasible15:37
lekernelwpwrak: if you do want USB on milkymist-ng, I can add that one. it's really no big deal.15:37
lekernelplus as I said, we might want to reintroduce USB at some point.15:38
wpwraknow we're making progress :)15:38
lekernelit won't be on the next board though, at least not with a user-accessible port15:39
wpwrakwe'll probably have marvelous usb support on m1 before there will even be a prototype of that next board :)15:40
wpwrakfor me it's basically a question of moving the whole thing over to linux. btw, how did your recent effort go ? did you find out why it didn't load executables ?15:41
lekernelnope. moved on to porting lua, which I think provides a clearer advantage in terms of application development productivity.15:42
wpwraklua, the programming language ?15:45
lekernelI want to write as much non performance-critical code in lua, e.g. interaction programming. doing it in C is annoying.15:47
wpwrakfor what role ? to rewrite flickernoise in it ? or for users, to program effects (replacing milkdrop) ?15:47
lekernelalso I think we won't have a OS, and do "multitasking" with IRQs like the demo firmware did15:48
lekernelRTEMS, besides having dirty code, did cause some fps drop compared to the irq-driven demo firmware15:48
lekerneland regarding the needs...15:49
lekernelYAFFS already provides a nice filesystem API15:49
lekerneluIP looks quite OK15:49
lekerneland there's actually not much more.15:49
wpwraksounds all very custom. that means high long-term maintenance effort.15:51
wolfspraullekernel: when do you start with the new devel board?15:53
wolfspraulthe kintex-7 one I mean15:53
lekernelwpwrak: linux actually sounds like both short and long term effort. first you need to fix things you could do without, like executable loader issues (we have one single app!) or a complete userland. then you have to fix regressions introuduced by other kernel developers.15:55
lekernelwolfspraul: in a few months I think15:56
wolfspraulshould we expect any no-regression updates for m1 in the meantime?15:57
lekernelmaybe one with mwalle's USB patches16:00
wpwraklekernel: i'm not terribly worried about other kernel developers fouling up things. first, it doesn't happen all that often. second, when it happens, they're usually very motivated to help :)16:02
wpwrakby the way, a plan B would be to port the new memory interface from migen to verilog. that would give us the same regression-free upgrade as porting the "legacy features" into migen.16:04
wpwrakand it would have the advantage that people who want to contribute have a bit less to learn. of course, it would remove a possibility for forcing people to deal with migen :)16:04
Action: roh doesnt get what removing midi, dmx and usb should help. it would kill all usecases i tried to get people to test it for.16:16
wolfspraulroh: no worries I think many people will continue with m1 and the highest degree of milkymist continuity anyway16:18
wolfspraulI only care about what that thing can actually do16:18
wolfspraulsebastien goes ahead and tries some interesting new things - why not16:19
wolfspraulactually don't know why wait several months?16:19
wolfspraulmaybe he first has to finish some of the lua/gui stuff? don't know16:19
rohwolfspraul: i can only say: what was described here is indistinguishable from a develboard which already exist.16:19
rohremoving everything which differenciates yourself from stuff that exists sounds like a good way to waste money. nothing else.16:20
wolfspraulit's a devel board on which one can do some hacking :-)16:20
rohwolfspraul: buy one. these exist.16:20
rohno need to make schems16:20
wolfspraulI continue with m1 :-)16:20
rohdigilent fro example16:21
wolfspraulI'm not interested in devel boards because they bypass the hard part which is to fix the bugs that regular people run into16:21
wolfsprauland that is also the part that creates value, if it's actually being addressed16:22
wpwrakroh: i suspect the radical feature removal plan will change once we have m1r4 do proper usb :)16:22
rohwolfspraul: regular people have no clue what to do with a 'reduced' mm1.16:23
wpwrakroh: i can understand why sebastien is afraid of usb. but it's a problem we already know how to solve. just needs a bit of work.16:23
wolfspraulsorry really late now, will read the backlog tomorrow16:23
rohno usb -> not extendable. no midi, no dmx,... how the fuck should they use itß16:23
wolfspraulthanks for caring!16:23
wolfspraulno worries of course I feel the same and I only care about users16:23
wolfspraulthose users have given me a pretty endless list of bugs and missing features (on m1) over the last year or so16:24
wolfsprauland I won't run away from that feedback, in fact I enjoy every day of working on this thing16:24
rohwpwrak: thats a problem in HIS mind. usb is default nowadays. not getting it to work means one either didnt try enough or should used parts which already work16:24
rohfrom my pov that means: make something that exposes navre-usb more ohci or uhci like to the upside, and use a proper usb stack.16:25
rohnot having hubs work is childish at best. i got laughed at because of that.16:26
wpwrakroh: sebastien's idea is to have a touch screen for control. that would eliminate the requirement for midi and dmx for control inputs. of course, users may still prefer some midi devices over the interface.16:26
rohwpwrak: i have people asking for stuff they can control and script better remotly.16:26
wolfspraulno hubs is just one in a *VERY LONG* list of things people would just take for granted on something like m116:27
wpwrakroh: (usb) oh, i totally agree. perhaps not ohci but something a little more adapted. writing a host controller driver isn't all that scary.16:27
wolfsprauldo we need to list it here? I doubt it16:27
rohever tried standing next to a dj in a booth on a party a full night? annoying, loud, etc. doing vj stuff is much more preparation that live act it seems.16:27
rohwpwrak: exactly.16:27
rohwolfspraul: i just mention it because hubs are like 'baseline' profile for usb. dont do that and i think you should not call it 'supporting usb anything'16:28
rohforget touchscreen. only wastes your money and doesnt help sell it.16:29
rohatleast everybody i showed it to asked rather if there is a rackmountable option.16:29
wpwrakhubs are a little scary for all the protocol stuff they need. so i understand why we don't support then now.16:29
rohthan for direct control foo.16:29
wpwrakbut with a proper stack, there'd be no excuse16:29
rohwpwrak: usb is a bit scary. thats why people use stacks and not reinvent the wheel every product they do.16:30
rohusually ;)16:30
wpwrakyeah. this is a little historical mistake we need to rectify :)16:30
Action: roh really doesnt want to nitpick. i know how hard all this is to engineer. but its neccessary to see the reality from more distance from time to time to get out of that focus hole which makes reality distort too much.16:34
rohso from my pov. sure. using linux for usb, eth and similar stacks would be nice. but then you also need a cpu which doesnt suck when it comes to execution speed.16:35
wpwrakyeah, i agree that usb is pretty much a sine qua non. i don't particularly like it, but there's no way around it. you have to be able to jump at least that high to be permitted to the game at all.16:35
rohso add one. 200mhz arm9 or mips is already enough. 80mhz isnt.16:36
roh80mhz is like over a decadade ago when i compare it to low-end consumer electronics. (set-top-boxes back then had 66-100mhz mips and ppc cpus)16:37
lekernelwpwrak: not touch screen16:37
wpwrakwe'll see how things go with linux. i don't really expect it to suck too badly.16:37
rohtft displays come in all sizes. and are dirt cheap.16:37
wpwraklekernel: well, "touch screen" is the closest things to explain with two words :)16:37
rohwith case. building/packaging your own is making it expensive fast.16:37
lekernelroh: it's more a preparation than a live act because they fear not controlling exactly what's on the screen. hopefully, we can improve that.16:38
rohlekernel: the people want to do live stuff too, but most i only see prepraring a lot and then getting out of the cellar if possible. (often also because of the music)16:39
rohlive is more complicated and often their current setups do not allow for live work due to limits in their soft or hardware and also the number of screens avail.16:39
wpwrakif you're a vj and hate the music, perhaps you should rethink you career choices ;-)))16:39
rohthese matrox triplehead thingies seem popular. but it still means you need to be at the booth next to the dj everytime.16:40
rohwpwrak: not hate music, hate the music you get paid for.16:40
lekernelroh: I said: built in LCD + 2-3 HDMI ports16:40
wpwrakroh: "volksmusik" ? ;-)16:41
rohlekernel: my take is: change the case to something which CAN be rackmounted (all conns to the back) and no display. waste of money.16:41
rohand think of a way to support analog display somehow. i know of no club which has dvi or hdmi beamers.16:41
rohthey sometimes got inputs on some of the new beamers, but its not that i see people having hdmi cables anywhere. they often have really long vga lines16:42
lekernelno display means we have again all the problems that make people not write patches in FN16:43
wpwrakroh: naw, that wouldn't work with what he's after. but i think that "touch screen" might be better a completely separate product. just a sophisticated input device that connects to m1 or whatever16:43
rohlekernel: how should they? you removed the keyboard port (usb)16:43
wpwraklekernel: like the absence of introductory documentation ? ;-)16:43
rohalso people seldomly know how to script.16:44
wpwrakroh: and you have to motivate them to overcome their reluctances and fears16:44
rohwpwrak: i dont think you got marketing ;)16:44
wpwrakroh: for us, it's much easier to understand the power a scripting language promises16:44
rohas soon as one wants to educate his customer, he has lost him.16:45
rohmake an 'rubberwire and blocks' mode. that can also generate scripts to store. but displaying them graphical is helping i think16:45
wpwrakroh: oh, you wouldn't reach everybody. but you could reach more people. right now, how wrote the patches we have ? 99% sebastien (with ports from milkdrop), 1% some demos by me.16:46
lekernelroh: I don't want any script anymore. when people see that, they just switch in "not for me" mode. even good documentation won't solve it.16:46
wpwrak"milkymist patch town. population: 2"16:46
lekernelyeah exactly16:46
lekernelso this also removes the need for a keyboard, and in turn, USB. good.16:46
rohlekernel: i dont wonder. you had no documentation at all. not even me got it working.16:47
rohas i said. no usb. no sale-16:47
rohand internal display as well.16:47
rohbbl.. need to drive16:47
lekernelroh: I sincerely doubt you even tried16:48
wpwraklekernel: i think your critter would have a much higher potential for success if you disentangle it from milkymist. keep milkymist as a product but make that device something that can also work on a pc.16:50
wpwrakthat way, you don't have to worry about all the inconvenient things m1 has to do, plus you have the potential of reaching a lot more customers, with relatively little extra effort.16:51
lekernelno, we need distinctive hardware features. besides, they're cool.16:52
wpwrakyou already have the distinctive feature in the user interface16:52
wpwrakif your best argument doesn't convince people, why should they buy your second best argument ?16:53
wpwrakyou could still sell them as a bundle. and of course make sure they play really well with each other16:53
wpwrakdivide and conquer :)16:54
lekernelmaking it portable is more work, not sure if it's worth it17:08
lekernelbasically I want to make the reactable of video17:08
lekerneland I think this will solve many of the M1 problems17:08
wpwrakall i'm saying is that you can have a much more versatile product if you split it properly17:10
wpwrakthe ract could be a fairly dumb device: video in, input data out (over usb). you could use a simple mcu for it. no need for an fpga.17:11
wpwrakall the "smart" stuff would happen on the m117:12
lekernelnah, you need instant video feedback on the table itself17:15
wpwrak< 1 ms ?17:18
wpwrak(that's the worst-case latency usb introduces per se. add processing overhead as desired)17:19
wpwrakshould also make initial development easier: you just hook it up to a pc and can conveniently do your things there. no need to worry about broken compilers and such.17:21
kristianpaulwhat no touch, touch !!17:35
kristianpaulat least you are going to draw something that produces cool effects in dont see any other good reason..17:36
kristianpaulhand draw*17:37
kristianpaulmake patches is boring when is not live mode and you can see how variables react on the input17:40
kristianpaulwpwrak: wanting to resurect asic + fpga combo?17:47
wpwrakkristianpaul: the "touch screen" he's after is like this: www.reactable.com17:50
wpwrakand the combo would be a bit of a stretch: the ract would have only an MCU and the M1 would have ... well, whatever the M1 wants to have :)17:51
kristianpaulyup i had used a reactable the one big table before17:51
kristianpaulthat lready produce cool sounds (i remeber that part was/is closed source)17:52
kristianpaulvery interesting17:52
kristianpauloh, story again17:52
kristianpaulall movin to iWorld :)17:52
kristianpaulperhaps we should focus on making a good api for it and improve vide synthesis and more phisicals varialbles like sound or light control than an "cool" geek-like interface :)17:54
wpwraki think the price tag may scare some people :)17:55
kristianpaulis hard to beat an ipad those days..17:55
kristianpaulwhat price? app is just 9usd17:55
wpwraknaw, i mean of the real device. the ipad is just an emulation17:55
wpwraki think sebastien wants physical tokens there17:56
kristianpaulah real17:56
kristianpaulah oh !!17:56
kristianpaulbtw still reactable uses a projector .17:57
wpwrakyeah. there must be a reason for the price :)17:58
kristianpaulthis indeed would lower learning barrier, no manual !18:00
wpwrak"touch and go" :)18:07
lekernelyes, LCD + wacom-style RF18:08
lekernelthat will do the trick18:08
lekerneland we can probably use attiny's in the objects18:08
lekernelhttp://scanlime.org/2008/09/using-an-avr-as-an-rfid-tag/ ;)18:08
kristianpaulis the LCD that big as a reactable?18:09
lekernel(just kidding of course)18:09
lekernelyeah, use some fancy TV screen18:09
kristianpaulnice blog18:12
Action: kristianpaul likem sifteo concept18:15
kristianpaulinteractive blocks https://www.sifteo.com/18:21
kristianpaulwas pointed for the blog above you pointed18:21
kristianpaulimagine that block on the "milkytalble"18:23
lekernelah yes, we need a name too :)18:23
wpwrak"ract" ? :)18:28
lekernelmirtideo ?18:49
wpwrakthe -ideo would be from video, what's the mirt- ? from mirth ?18:53
wpwrak"hilarious video" ?18:54
wpwrakmirteo sounds better. less complicated :)19:44
wpwrakrussia has the tubeless tv ? amazing. (of course, this joke would be better on #qi-hw)22:53
wpwraki like this quote: "Technologist is the main person here."22:54
wolfspraulwpwrak: good morning :-)23:40
wolfspraulcan you tell us more about this separation you mad in mind?23:41
wolfspraulthe 'ract' here and 'the smart stuff' there? I didn't get it23:41
wpwrakmake the ract/mirteo simply a tablet/table device with video in (dvi or such) and the smarts needed to talk to the tokens. kinda like you'd make a wacom with display underneath23:44
wpwrakwe when you place/manipulate a token, the device would send out something over usb. and it would continuously display whatever comes in from the video input23:44
wpwrakthen you could connect a dual-head-capable m1, a pc, etc., and the host would do the bulk of the work23:46
wolfspraulthe ract is then just a touch-enabled lcd?23:46
wolfspraulor rather - the counter partner of the physical objects?23:47
wolfspraulor is it finger touchable as well?23:47
wpwrakdisadvantages: 1) m1+ract would be a bit more expensive than a single combined device. 2) very slight extra delay. 3) you have two items sitting around (but see roh's comment about racking)23:48
wpwraki don't think it would respond to a naked finger. and yes, the ract would be simply display plus "tablet". a rather fancy tablet, of course.23:48
wolfspraulthe video and touch data goes over usb?23:50
wpwrakadvantages: 1) lower complexity per device. 2) you can sell ract also to those who don't want an m1, and vice versa. 3) you don't need to couple the development. e.g., you could make a ract+  independent from, say, an m2.23:50
wolfspraulit supports multiple objects on it? but no finger?23:50
wolfsprauljust trying to understand this thing at all :-)23:50
wpwrakvideo would go over dvi or similar. of course, for prototyping, it could just be an 8 bit pixel bus. whatever is easiest.23:51
wpwrakthink wacom tablet. they don't normally recognize fingers. but i suppose they can recognize multiple object. at least in our case, this would be a necessity.23:52
wolfspraulit would be a device without functioning software support for a while23:53
wpwrak(multiple objects) even multiple concurrent objects in our case. wacom have different tools (pencil, brush, eraser, etc.) that the tablet can distinguish but i don't know if they could be on the surface at the same time23:53
wolfspraulwhat people (and companies) do nowadays is using the ipad23:53
wpwrakwell, every device starts like tat ;-)23:53
wolfspraulsure, I like the separation23:53
wpwrakyes, the question whether all this is worth the trouble is really whether the improvement over an pure pad solution is really that greay23:54
wolfspraulfor the sake of openess and full disclosure and positive milkymist future, I wanted to share what I think I can realistically do about new devices23:54
wpwraknow it comes :)23:54
wolfspraulI will definitely not get behind another attempt to 'productize' milkymist tech23:54
wolfspraulI don't run away from problems. with the m1 we have started something that after 2 years I can just say is one big story of over-promising.23:55
wolfspraulmassive over-promising23:55
wolfspraulbut that is ok, I don't mind because it goes into a new direction and we learn23:55
wolfspraulI will continue with m1 as an (attempted but failed) product, follow any hacking activities with interest, and otherwise think separately of a potential 3rd *PRODUCT* that I can get behind given what I learnt23:56
wolfspraulfor the time being, I feel pretty good how the m1 matures, I don't see the alternative23:56
wolfspraulof course it was crazy to try it this way :-)23:56
wolfsprauland the user reaction we got was spot on23:56
wpwrakso what does "continue with m1" mean ?23:56
wolfspraulwhat we do now. move to kicad, boomify the bom23:57
wpwrakokay, so no change in plans for m1r4 hardware23:57
wolfspraulwe have about 15 m1 in stock, sales are pretty much zero (rightfully so), so maybe we can make a small run and uprate those units in stock23:57
wpwrakare you thinking of producing m1r4 in more than prototype quantities ?23:58
wolfspraulI don't believe the m1 hardware as-is today can ever take off, because it is just an ocean of overpromising and nothing but disappointment for anyone who we can convince (talk into) buying one23:58
wolfspraulno, of course not!23:58
wolfspraulfor whom?23:58
wolfspraulnobody wants it :-)23:58
wolfspraulbut that doesn't mean I run away from it23:58
wolfspraulthat way of making a product has proven to be way too difficult23:58
wolfspraulfor the 3rd product, I only have vague ideas now23:59
wpwrakso the m1r4 work would be for the zen experience. the way is the goal.23:59
wolfspraulwhich are emerging, and will continue to emerge, out of everything we learnt over at #qi and m123:59
wolfspraulas I said maybe we can upgrade the units in stock23:59
wolfspraulremember: there are no sales23:59
wolfspraulwe don't need to make something nobody wants23:59
wolfspraulbtw, the same could be said about any ract/mirteo etc. plans23:59
--- Sun May 27 201200:00

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