lekernel changed the topic of #milkymist to: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs :: Something to do? Port NuttX to Milkymist SoC
<mwalle>
nice, ehsm on heise :)
<mwalle>
congratz
jimmythehorn has quit [Quit: jimmythehorn]
methril has quit [Read error: Operation timed out]
elldekaa has quit [Ping timeout: 260 seconds]
methril has joined #milkymist
elldekaa has joined #milkymist
xiangfu has joined #milkymist
Jia has joined #milkymist
Jia has quit [Client Quit]
elldekaa has quit [Ping timeout: 265 seconds]
xiangfu has quit [Quit: Leaving]
elldekaa has joined #milkymist
voidcoder has quit [Read error: Connection reset by peer]
elldekaa has quit [Remote host closed the connection]
rejon has joined #milkymist
voidcoder has joined #milkymist
sh[4]rm4 has quit [Remote host closed the connection]
sh[4]rm4 has joined #milkymist
sh[4]rm4 has quit [Remote host closed the connection]
<lekernel>
but it only takes DDR3 modules, which are a pain in the ass as I already mentioned
<lekernel>
I want to remove the non-distinctive features of the M1 and add good distinctive ones
<lekernel>
basically, 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)
* kristianpaul
likes the reactable-style interface
<wolfspraul>
sure, nice
<wolfspraul>
the 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?
<lekernel>
yes
<wolfspraul>
flash I personally would prefer SPI now
<wolfspraul>
digital video-in and out is great
<wolfspraul>
what are 'expansion' ports?
<lekernel>
just the same sort of connector that we have now
<lekernel>
directly routed to fpga
<wolfspraul>
you remove what?
<wolfspraul>
vga
<wolfspraul>
analog video in
<wolfspraul>
midi
<wolfspraul>
dmx
<wolfspraul>
even usb?
<lekernel>
yes, especially usb
<lekernel>
it's a pain and people take it for granted
<wolfspraul>
we can continue to develop it on the m1
<lekernel>
yes
<lekernel>
:)
<wolfspraul>
we absolutely need to watch for continuity between the m1 and this new board
<wolfspraul>
'continuity' in the sense of 1 unified source tree primarily, binary compatibility is another matter
<wolfspraul>
sure 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 good
<lekernel>
as 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.
<kristianpaul>
wait, so video in will come as hdmi too?
<lekernel>
yeah, we should have bidirectional HDMI ports
<kristianpaul>
or no more this feature about mix video with effects etc?
<kristianpaul>
good
<wolfspraul>
the goal would be that nothing much needs to be 'specifically developed for m1'
<wolfspraul>
what is the migen plan actually?
<wolfspraul>
is it realistic that it will fully work (on m1), soonish/later/never?
<lekernel>
it works on M1 today
<wolfspraul>
I mean we can push out an update that was built with migen in the background and people won't complain about missing things :-)
<lekernel>
well, then you need to port USB, MIDI, DMX, ...
<kristianpaul>
USB at least ;-)
<wolfspraul>
that sounds like no migen release is planned for m1
<kristianpaul>
or internal usb
<lekernel>
hope that you have enough memory bandwidth to run the new software
<kristianpaul>
migen is been developed for m1 right now? no?
<wolfspraul>
who hopes? don't understand
<lekernel>
also you need to redesign the UI, which won't be mouse-based anymore
<kristianpaul>
ah wait, migen for m1 will not improve memory speed?
<lekernel>
the backport will be quite some of work.
<lekernel>
kristianpaul: it does. but ddr3 will improve it even more.
<wolfspraul>
we need a dose of honesty and realism here
<wolfspraul>
I think there will be no fully functioning migen for m1, ever
<wolfspraul>
I just say 'fully functioning' instead of 'working' now :-)
<lekernel>
btw migen != milkymist-ng
<wolfspraul>
ah
<wolfspraul>
tell us more
<lekernel>
migen is the new tool to build the milkymist-ng soc
<lekernel>
well, there can be, but as always - someone has to do it
<wolfspraul>
if you are not planning to do it, it will never happen
<wolfspraul>
which is ok, we just need to be open about it, imho
<lekernel>
he. 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?
<wolfspraul>
I don't feel I should tell you what you 'should' do, milkymist is doing quite well imo
<wolfspraul>
you did a great job
<wolfspraul>
people are learning about the soc, digital design, fpgas, etc.
<wolfspraul>
the big product uptake has not happened, but at least from the things I learned in the last 2 years, I am not surprised about that
<wolfspraul>
most of the things I learned is about what does *not* work :-)
<lekernel>
so. backporting next-MM features into the M1 sounds like a great learning project. and I would support such initiatives.
<wolfspraul>
sure sure
<wolfspraul>
but that's just meaningless blurb for 'will not happen'
<wolfspraul>
people are better off following the new thing then
<wolfspraul>
of course
<wolfspraul>
I like the new design/board idea
<wolfspraul>
throw out all the old stuff, focus on new, carry forward the good things
<wolfspraul>
for m1 that means something like 'milkymist legacy' or so
<wolfspraul>
no idea right now how new products can come out of it, more or less abandoned on the soc level
<wolfspraul>
I don't see a big problem if you 'move on' from the m1 soc
<lekernel>
I did the hard part already
<lekernel>
the DDR is working
<lekernel>
:)
<lekernel>
(on the M1)
<wolfspraul>
that's besides the point because nobody will ever use it
<wolfspraul>
in reality, not from what you think someone 'might' or 'should' do
<wolfspraul>
nobody will
<wpwrak>
if we abandon milkymist, does it even make sense to produce m1r4 then ?
<wolfspraul>
but anyway, I agree with your thinking
<wolfspraul>
he
<wolfspraul>
'abandon milkymist' goes a little far
<wolfspraul>
we are overwhelmed in actually getting the new migen/-ng stuff fully "backported" to m1
<wpwrak>
well, it still has numerous issues that could be fixed without having to move to new hardware
<wolfspraul>
not that much surprised about that
<wolfspraul>
and to sebastien it appears better to focus on new things only, which I can understand
<wpwrak>
and m1r4 will need even new development, e.g., for dvi
<wolfspraul>
that would overlap with the new focus on digital video in and out
<lekernel>
that DVI development will be useful for the next product too
<wpwrak>
as i understand things, migen is a prerequisite for faster memory
<wolfspraul>
I don't think that migen thing will happen on m1
<wolfspraul>
not fully
<wpwrak>
without migen for m1r4, dvi will therefore be useless
<wolfspraul>
there is just not enough momentum/motivation
<kristianpaul>
i'm worried more about software support right now than hardware improvements at all (besides memory speed)
<lekernel>
wpwrak: at least, you'll have a framebuffer
<wolfspraul>
I am just realistic - unless sebastien finishes the -ng support on m1 100%, it will not happen
<wolfspraul>
whatever empty words of 'nice entry-level task' we wrap around that
<lekernel>
with high resolution and 10:10:10 color depth
<lekernel>
running on the new memory infrastructure
<wpwrak>
kristianpaul: memory speed also gives us issues like the "fade to green" effect. that limits the device's abilities quite a bit
<wpwrak>
lekernel: (new memory infrastructure) that's the new device ? or milkymist ?
<lekernel>
that's M1
<wolfspraul>
in terms of 'productization', I will probably stay on m1 and see how I can get some incremental improvements going there
<lekernel>
the infrastructure that I'm prototyping today on the M1 will be on the next device - only with DDR3 and more chips
<wolfspraul>
if we zoom out, one could say that we totally overwhelmed ourselves in making the features on m1 actually work good
<wolfspraul>
so what we learned from that is to dramatically cut features by 90% or more
<wolfspraul>
and make a new board
<wpwrak>
lekernel: so you plan on making migen suitable for replacing the existing gateware ?
<wpwrak>
lekernel: (on M1)
<wolfspraul>
while we leave the old, overwhelming, design in the background hoping that it will slowly emerge
<lekernel>
wpwrak: to a certain extent, yes. but I will not develop features that won't be present at all on the next product.
<lekernel>
though if someone does it, I won't refuse the patches
<wolfspraul>
such as midi, dmx, usb, infrared, ... :-)
<lekernel>
yes
<wolfspraul>
so basically m1 is abandoned, from that perspective
<wolfspraul>
but I agree we have to CUT CUT CUT features
<wolfspraul>
somewhere
<wpwrak>
a rather disappointing development
<wpwrak>
so all the work we put into m1r4 was wasted
<wolfspraul>
I don't see it like that
<wpwrak>
lekernel: you have an interesting way of motivating people ;-)
<wolfspraul>
maybe my expectations already were different for months :-)
<lekernel>
he
<wolfspraul>
m1 is a lesson in overpromising
<wolfspraul>
by a factor of 100, at least
<lekernel>
it's not even hard to reuse the legacy verilog with migen
<wolfspraul>
until today I am sure I can easily find keyboard & mice that won't work
<wolfspraul>
don't even get me started about any of the other stuff
<lekernel>
having USB with the current code on milkymist-ng on M1 can probably be done in a few hours by someone with no prior migen experience
<wolfspraul>
honesty
<lekernel>
and same for most of the cores, except the few ones that use DMA direct to the DRAM because the memory system is very different there
<wolfspraul>
you are not planning to do it
<wolfspraul>
you should say so
<lekernel>
I already have
<wolfspraul>
and from what I learned over the last 2 years, I take a bet that that means "it will not happen"
<wolfspraul>
usb?
<wolfspraul>
I was replying to the usb comment
<wpwrak>
if it's so easy, it would probably more efficient for you to do it than to argue about why you won't do it ;)
<lekernel>
yes. this goes under the more general "features that will not be present at all on the next product"
<wolfspraul>
you don't need to convince me anyway, since I am forming my own opinion
<wolfspraul>
I agree to abandon m1 from your perspective and focus on a new board as outlined above
<wolfspraul>
CUT features
<wolfspraul>
and 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 well
<lekernel>
though actually, for USB, we might actually reintroduce it at some point
<wolfspraul>
even thouhg that is outside of the scope of your work
<wolfspraul>
exactly
<lekernel>
it's (unfortunately) too well spread that we can ignore it so easily
<wolfspraul>
I like the new board
<wolfspraul>
(the idea)
<wolfspraul>
m1 is essentially a devel board for 10-20 people
<wolfspraul>
the attempt to productize it failed
<wolfspraul>
and that new board will also be a devel board for a few people
<lekernel>
so USB developments on M1 still make sense, I think. in the long term.
<wolfspraul>
yes
<wolfspraul>
and we need those new features anyway, -7, ddr3, digital video in and out
<wolfspraul>
so 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 platform
<wolfspraul>
that's my thinking
<wolfspraul>
it's not like we don't have another few hundred (or thousand) bugs on m1 left :-)
<wpwrak>
i 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.
<wolfspraul>
'bugs' as in "things regular people would like to do"
<wolfspraul>
Sebastien will see linux along the lines of usb
<wolfspraul>
big old legacy stuff
<wolfspraul>
I think sebastien should charge ahead with the new board
<wolfspraul>
that plays to his strengths
<wolfspraul>
we have to catch up with the base and think about what products can be formed out of all this
<wpwrak>
i see a disconnect regarding migen. at least the pixel size and all that entails seems essential for m1-as-a-vj-system.
<wolfspraul>
I 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.
<wolfspraul>
yes but I think sebastien will not 'finish' migen or -ng for m1
<wolfspraul>
it's too much work
<lekernel>
wpwrak: what's "pixel size"?
<wpwrak>
with migen on the m1, without a regression in functionality, i'd see much less of a problem in maintaining it without sebastien
<lekernel>
wolfspraul: actually you will have VGA/DVI working
<wolfspraul>
so we have some half-finished thing that 'works' but of course no update can be pushed out etc.
<wolfspraul>
lekernel: I need a coherent update
<wpwrak>
lekernel: bits per pixel
<wolfspraul>
if we have that - great
<wolfspraul>
even if the build/synthesis process is messy, doesn't matter
<wolfspraul>
but until we don't have that, it's not there
<lekernel>
wolfspraul: and pfpu/tmu hw acceleration
<wolfspraul>
we 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 worse
<lekernel>
audio and usb can be backported easily by just linking the legacy verilog, and with that you have a basic rendering system
<wolfspraul>
so either there are no regressions, or it's not an 'update'
<wpwrak>
"new patch language: VHDL" ;-)
<wolfspraul>
you plan to do that?
<lekernel>
video-in is a bit more trouble and needs some architecture understanding
<kristianpaul>
wpwrak: ha
<wolfspraul>
when you say 'easily' that sometimes means you think someone else can do it easily :-)
<wolfspraul>
I'm not pushing you to do it btw
<wolfspraul>
I already explained above that I think you play to your strength by focusing on that new board
<wolfspraul>
and we know you will review any m1-related patches in good faith
<wolfspraul>
only that there will be no such patches, or very few
<wolfspraul>
but what can you do
<wolfspraul>
we cannot get stuck there
<lekernel>
and 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 32
<wolfspraul>
trust me - if Sebastien is not *finishing* those things, they won't happen
<wolfspraul>
which is ok, we just need to be open about it
<wolfspraul>
because even if he would sit down and do all that - what is gained?
<wpwrak>
lekernel: i thought migen had the increased pixel depth already ?
<wolfspraul>
it's better to focus on the future
<lekernel>
wpwrak: there's no video stuff yet
<wpwrak>
lekernel: the dependency chain i see is pixel depth || dvi -> memory bw -> migen
<lekernel>
but I think the M1 can definitely render in 640x480 at 32bpp with the -ng memory controller
<wpwrak>
wolfspraul: 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.
<wolfspraul>
who will deliver this update?
<wolfspraul>
we have tried to sell a lot of hot air with m1 in the past
<wolfspraul>
for the things I learned, I will not continue to do that
<wolfspraul>
so one by one as I learn what does *not* work, I stop trying to use that to sell, of course
<wolfspraul>
because it cannot work
<wolfspraul>
if Sebastien does not plan to finish this work and update it all the way to a 'zero regression' state, then it will not happen
<wolfspraul>
that's a pretty binary thing
<wolfspraul>
either the actual update (for a user) happens, or not
<wolfspraul>
and time is ticking
<wolfspraul>
that's not wishful thinking
<wolfspraul>
not a 'plan'
<wolfspraul>
or 'easy'
<wolfspraul>
or "just a few"
<wolfspraul>
or any of that
<wolfspraul>
the update is either there or not
<wolfspraul>
if not - ok
<lekernel>
not from me
<lekernel>
but as a migen/milkymist-ng development board, the M1 is still there.
<wpwrak>
it'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.
<wolfspraul>
I doubt that will happen
<lekernel>
with (at least coming from me) a basic SoC working, i.e. cpu, memory, framebuffer
<wolfspraul>
sebastien will move m1 to a "I review patches when I get them" mode
<wpwrak>
once we have a basis that can actually run the existing stuff, taking care for maintenance (in a wide sense) sounds a lot more feasible
<lekernel>
wpwrak: if you do want USB on milkymist-ng, I can add that one. it's really no big deal.
<lekernel>
plus as I said, we might want to reintroduce USB at some point.
<wpwrak>
now we're making progress :)
<lekernel>
it won't be on the next board though, at least not with a user-accessible port
<wpwrak>
we'll probably have marvelous usb support on m1 before there will even be a prototype of that next board :)
<wpwrak>
for 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 ?
<lekernel>
nope. moved on to porting lua, which I think provides a clearer advantage in terms of application development productivity.
<wpwrak>
lua, the programming language ?
<lekernel>
yes
<lekernel>
I want to write as much non performance-critical code in lua, e.g. interaction programming. doing it in C is annoying.
<wpwrak>
for what role ? to rewrite flickernoise in it ? or for users, to program effects (replacing milkdrop) ?
<lekernel>
also I think we won't have a OS, and do "multitasking" with IRQs like the demo firmware did
<lekernel>
RTEMS, besides having dirty code, did cause some fps drop compared to the irq-driven demo firmware
<lekernel>
and regarding the needs...
<lekernel>
YAFFS already provides a nice filesystem API
<lekernel>
uIP looks quite OK
<lekernel>
and there's actually not much more.
jimmythehorn has joined #milkymist
<wpwrak>
sounds all very custom. that means high long-term maintenance effort.
<wolfspraul>
lekernel: when do you start with the new devel board?
<wolfspraul>
the kintex-7 one I mean
<lekernel>
wpwrak: 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.
<lekernel>
wolfspraul: in a few months I think
<wolfspraul>
should we expect any no-regression updates for m1 in the meantime?
<lekernel>
maybe one with mwalle's USB patches
jimmythehorn has quit [Quit: jimmythehorn]
<wpwrak>
lekernel: 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 :)
<wpwrak>
by 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.
<wpwrak>
and 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 :)
jimmythehorn has joined #milkymist
* 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.
<wolfspraul>
roh: no worries I think many people will continue with m1 and the highest degree of milkymist continuity anyway
<wolfspraul>
I only care about what that thing can actually do
<wolfspraul>
sebastien goes ahead and tries some interesting new things - why not
<wolfspraul>
actually don't know why wait several months?
<wolfspraul>
maybe he first has to finish some of the lua/gui stuff? don't know
<roh>
wolfspraul: i can only say: what was described here is indistinguishable from a develboard which already exist.
<wolfspraul>
sure
<roh>
removing everything which differenciates yourself from stuff that exists sounds like a good way to waste money. nothing else.
<wolfspraul>
it's a devel board on which one can do some hacking :-)
<roh>
wolfspraul: buy one. these exist.
<roh>
no need to make schems
<wolfspraul>
sure
<wolfspraul>
I continue with m1 :-)
<roh>
digilent fro example
<wolfspraul>
I'm not interested in devel boards because they bypass the hard part which is to fix the bugs that regular people run into
<wolfspraul>
and that is also the part that creates value, if it's actually being addressed
<wpwrak>
roh: i suspect the radical feature removal plan will change once we have m1r4 do proper usb :)
<roh>
wolfspraul: regular people have no clue what to do with a 'reduced' mm1.
<wpwrak>
roh: 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.
<wolfspraul>
sorry really late now, will read the backlog tomorrow
<roh>
no usb -> not extendable. no midi, no dmx,... how the fuck should they use itß
<wolfspraul>
thanks for caring!
<wolfspraul>
no worries of course I feel the same and I only care about users
<wolfspraul>
those users have given me a pretty endless list of bugs and missing features (on m1) over the last year or so
<wolfspraul>
and I won't run away from that feedback, in fact I enjoy every day of working on this thing
<roh>
wpwrak: 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 work
<roh>
from my pov that means: make something that exposes navre-usb more ohci or uhci like to the upside, and use a proper usb stack.
<roh>
not having hubs work is childish at best. i got laughed at because of that.
<wpwrak>
roh: 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.
<roh>
bwhahahaha
<roh>
wpwrak: i have people asking for stuff they can control and script better remotly.
<wolfspraul>
no hubs is just one in a *VERY LONG* list of things people would just take for granted on something like m1
<wpwrak>
roh: (usb) oh, i totally agree. perhaps not ohci but something a little more adapted. writing a host controller driver isn't all that scary.
<wolfspraul>
do we need to list it here? I doubt it
<roh>
ever 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.
<roh>
wpwrak: exactly.
<roh>
wolfspraul: 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'
<roh>
forget touchscreen. only wastes your money and doesnt help sell it.
<roh>
atleast everybody i showed it to asked rather if there is a rackmountable option.
<wpwrak>
hubs are a little scary for all the protocol stuff they need. so i understand why we don't support then now.
<roh>
than for direct control foo.
<wpwrak>
but with a proper stack, there'd be no excuse
<roh>
wpwrak: usb is a bit scary. thats why people use stacks and not reinvent the wheel every product they do.
<roh>
usually ;)
<wpwrak>
yeah. this is a little historical mistake we need to rectify :)
* 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.
<roh>
so 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.
<wpwrak>
yeah, 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.
<roh>
so add one. 200mhz arm9 or mips is already enough. 80mhz isnt.
<roh>
80mhz 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)
<lekernel>
wpwrak: not touch screen
<wpwrak>
we'll see how things go with linux. i don't really expect it to suck too badly.
<roh>
tft displays come in all sizes. and are dirt cheap.
<wpwrak>
lekernel: well, "touch screen" is the closest things to explain with two words :)
<roh>
with case. building/packaging your own is making it expensive fast.
<lekernel>
roh: 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.
<roh>
lekernel: 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)
<roh>
live 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.
<wpwrak>
if you're a vj and hate the music, perhaps you should rethink you career choices ;-)))
<roh>
these matrox triplehead thingies seem popular. but it still means you need to be at the booth next to the dj everytime.
<roh>
wpwrak: not hate music, hate the music you get paid for.
<lekernel>
roh: I said: built in LCD + 2-3 HDMI ports
<wpwrak>
roh: "volksmusik" ? ;-)
<roh>
lekernel: my take is: change the case to something which CAN be rackmounted (all conns to the back) and no display. waste of money.
<roh>
and think of a way to support analog display somehow. i know of no club which has dvi or hdmi beamers.
<roh>
they 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 lines
<lekernel>
no display means we have again all the problems that make people not write patches in FN
<wpwrak>
roh: 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 whatever
<roh>
lekernel: how should they? you removed the keyboard port (usb)
<wpwrak>
lekernel: like the absence of introductory documentation ? ;-)
<roh>
also people seldomly know how to script.
<wpwrak>
roh: and you have to motivate them to overcome their reluctances and fears
<roh>
wpwrak: i dont think you got marketing ;)
<wpwrak>
roh: for us, it's much easier to understand the power a scripting language promises
<roh>
as soon as one wants to educate his customer, he has lost him.
<roh>
make an 'rubberwire and blocks' mode. that can also generate scripts to store. but displaying them graphical is helping i think
<wpwrak>
roh: 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.
<lekernel>
roh: 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.
<wpwrak>
"milkymist patch town. population: 2"
<lekernel>
yeah exactly
<lekernel>
so this also removes the need for a keyboard, and in turn, USB. good.
<roh>
lekernel: i dont wonder. you had no documentation at all. not even me got it working.
<roh>
as i said. no usb. no sale-
<roh>
and internal display as well.
<roh>
bbl.. need to drive
<lekernel>
roh: I sincerely doubt you even tried
<wpwrak>
lekernel: 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.
<wpwrak>
that 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.
<lekernel>
no, we need distinctive hardware features. besides, they're cool.
<wpwrak>
you already have the distinctive feature in the user interface
<wpwrak>
if your best argument doesn't convince people, why should they buy your second best argument ?
<wpwrak>
you could still sell them as a bundle. and of course make sure they play really well with each other
<wpwrak>
divide and conquer :)
<lekernel>
making it portable is more work, not sure if it's worth it
<lekernel>
basically I want to make the reactable of video
<lekernel>
and I think this will solve many of the M1 problems
<wpwrak>
all i'm saying is that you can have a much more versatile product if you split it properly
Gurty` has joined #milkymist
<wpwrak>
the 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.
<wpwrak>
all the "smart" stuff would happen on the m1
Gurty has quit [Ping timeout: 265 seconds]
<lekernel>
nah, you need instant video feedback on the table itself
<wpwrak>
< 1 ms ?
<wpwrak>
(that's the worst-case latency usb introduces per se. add processing overhead as desired)
<wpwrak>
should 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.
froggytoad is now known as ftoad
<kristianpaul>
what no touch, touch !!
<kristianpaul>
at least you are going to draw something that produces cool effects in dont see any other good reason..
<kristianpaul>
hand draw*
<kristianpaul>
make patches is boring when is not live mode and you can see how variables react on the input
<kristianpaul>
wpwrak: wanting to resurect asic + fpga combo?
<wpwrak>
kristianpaul: the "touch screen" he's after is like this: www.reactable.com
<wpwrak>
and 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 :)
<kristianpaul>
yup i had used a reactable the one big table before
<kristianpaul>
that lready produce cool sounds (i remeber that part was/is closed source)
<kristianpaul>
very interesting
<kristianpaul>
oh, story again
<kristianpaul>
all movin to iWorld :)
<kristianpaul>
perhaps 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 :)
<wpwrak>
i think the price tag may scare some people :)
<kristianpaul>
is hard to beat an ipad those days..
<kristianpaul>
what price? app is just 9usd
<wpwrak>
naw, i mean of the real device. the ipad is just an emulation
<kristianpaul>
sure
<wpwrak>
i think sebastien wants physical tokens there
<kristianpaul>
ah real
<kristianpaul>
ah oh !!
<kristianpaul>
btw still reactable uses a projector .
<wpwrak>
yeah. there must be a reason for the price :)
<kristianpaul>
he
<kristianpaul>
this indeed would lower learning barrier, no manual !
<wpwrak>
"touch and go" :)
<lekernel>
yes, LCD + wacom-style RF
<lekernel>
that will do the trick
<lekernel>
and we can probably use attiny's in the objects
<wpwrak>
russia has the tubeless tv ? amazing. (of course, this joke would be better on #qi-hw)
<wpwrak>
i like this quote: "Technologist is the main person here."
<wolfspraul>
wpwrak: good morning :-)
<wolfspraul>
can you tell us more about this separation you mad in mind?
<wolfspraul>
the 'ract' here and 'the smart stuff' there? I didn't get it
<wpwrak>
make 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 underneath
<wpwrak>
we 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 input
<wpwrak>
then you could connect a dual-head-capable m1, a pc, etc., and the host would do the bulk of the work
<wolfspraul>
the ract is then just a touch-enabled lcd?
<wolfspraul>
or rather - the counter partner of the physical objects?
<wolfspraul>
or is it finger touchable as well?
<wpwrak>
disadvantages: 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)
<wpwrak>
i 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.
<wolfspraul>
the video and touch data goes over usb?
<wpwrak>
advantages: 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.
<wolfspraul>
it supports multiple objects on it? but no finger?
<wolfspraul>
just trying to understand this thing at all :-)
<wpwrak>
video would go over dvi or similar. of course, for prototyping, it could just be an 8 bit pixel bus. whatever is easiest.
<wpwrak>
think 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.
<wolfspraul>
it would be a device without functioning software support for a while
<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 time
<wolfspraul>
what people (and companies) do nowadays is using the ipad
<wpwrak>
well, every device starts like tat ;-)
<wolfspraul>
sure, I like the separation
<wpwrak>
yes, the question whether all this is worth the trouble is really whether the improvement over an pure pad solution is really that greay
<wpwrak>
s/greay/great/
<wolfspraul>
for the sake of openess and full disclosure and positive milkymist future, I wanted to share what I think I can realistically do about new devices
<wpwrak>
now it comes :)
<wolfspraul>
I will definitely not get behind another attempt to 'productize' milkymist tech
<wolfspraul>
I 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.
<wolfspraul>
massive over-promising
<wolfspraul>
but that is ok, I don't mind because it goes into a new direction and we learn
<wolfspraul>
I 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 learnt
<wolfspraul>
for the time being, I feel pretty good how the m1 matures, I don't see the alternative
<wolfspraul>
of course it was crazy to try it this way :-)
<wolfspraul>
and the user reaction we got was spot on
<wpwrak>
so what does "continue with m1" mean ?
<wolfspraul>
what we do now. move to kicad, boomify the bom
<wpwrak>
okay, so no change in plans for m1r4 hardware
<wolfspraul>
we 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 stock
<wpwrak>
are you thinking of producing m1r4 in more than prototype quantities ?
<wolfspraul>
I 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 one
<wolfspraul>
no, of course not!
<wolfspraul>
for whom?
<wolfspraul>
nobody wants it :-)
<wolfspraul>
but that doesn't mean I run away from it
<wolfspraul>
that way of making a product has proven to be way too difficult
<wolfspraul>
for the 3rd product, I only have vague ideas now
<wpwrak>
so the m1r4 work would be for the zen experience. the way is the goal.
<wolfspraul>
which are emerging, and will continue to emerge, out of everything we learnt over at #qi and m1
<wolfspraul>
no
<wolfspraul>
as I said maybe we can upgrade the units in stock
<wolfspraul>
remember: there are no sales
<wolfspraul>
we don't need to make something nobody wants
<wolfspraul>
btw, the same could be said about any ract/mirteo etc. plans