Topic for #milkymist is now Radical Tech Coalition :: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
cladamw has joined #milkymist
cozy has joined #milkymist
<cozy> Hi
<cozy> Is there any way to get the manual for the flickernoise language?
<cozy> Anyone know where that is?
<cozy> nm
<cozy> found it
<cozy> ok, would it be possible to run flickernoise on a regular laptop?
<cozy> i.e. is there a way to emulate flickernoise on an osx or windows machine?
<cozy> or on a linux install with a realtime kernel?
<cozy> ok, and another thing
<cozy> how would i go about writing a patch and testing it?
<cozy> is there a provision for writing patches and testing them within the milkymist itself?
<cozy> don't worry, i'll idle hard until someone replies
<hypermodern> lekernel, is there any higher resolution images from this page http://milkymist.org/wp/2011/12/diversity-of-programmable-effects/
xiangfu has joined #milkymist
<cozy> So basically, I'm working with a company that wants to implement Milkymists into a live setting... We would like to be able to edit and upload patches on the fly, during performances, and to have the Milkymist react to MIDI notes, program and control changes in realtime
<xiangfu> cozy, Hi
<cozy> Hello
<xiangfu> welcome to Milkymist :)
<cozy> I thank you kindly
<cozy> I'm excited about the MM One!
<xiangfu> you already found the manual
<cozy> No
<cozy> I don't have it
<cozy> My buddy said he found it but I'm not on the phone with him right now
<cozy> Is there a comprehensive one you can reccomend?
<cozy> Awesome, thank you
<xiangfu> I think the best would be buy a Milkymist One. write and test patch on it. :)
<cozy> Heh
<cozy> Well, I'm all for it, it's a matter of convincing the others
<kristianpaul> indeed
<cozy> I think it will do everything we'd like it to
<kristianpaul> flickernoise is very customized for running on a M1
<cozy> That's what I figured
<xiangfu> :) I don't think there is a problem that can emulate the whole Flickernoise.
<cozy> So is there a way to create and upload a patch on the fly, while the Milkymist One is running?
<kristianpaul> wich customized i meant, because the sepcialiezed hardware for video effects of course :)
<cozy> Yeah
<cozy> Realtime kernel and all that
<kristianpaul> i guess you alreayd know project-m
<cozy> I would think it would take a performance hit if you had it on anything but a comparable Linux realtime install
<cozy> Yeah, a little bit
<cozy> I just "discovered" all this today
<kristianpaul> ah :-)
<cozy> :D
<kristianpaul> What called you atention from Milkymist?
<xiangfu> project-m don't react to MIDI and no Video synthesizer
<xiangfu> cozy, the very key feature is that the MIlkymist can synthesis live Video. at the same time it can controller DMX. react to MIDI.
<xiangfu> and sound.
<cozy> kristianpaul, I was digging around on Wikipedia to find out about OSC compatible hardware
<xiangfu> ( implement Milkymists into a live setting... ) what do you mean of this? you want take all Milkymist software. implement to your hardware. or you just want a Milkymist One as part of your device?
<cozy> xiangfu, that's the main reason I'm interested in it
<cozy> What we'd like to do is have a central machine that handles MIDI data from guitar pickups and routes it to (multiple) Milkymist setups
<cozy> And drum triggers
<cozy> Maybe some audio to MIDI vst's
<cozy> and later down the line spatial sensors, accelerometers, motion sensors, pressure, etc.
<cozy> xiangfu, we'd like to implement Milkymist Ones into a multimedia performance environment
<cozy> a mobile one
<cozy> i.e. production company
<cozy> we're looking to unify our local scene here by creating a setting that like-minded acts and their audiences can feel "immersed" in
<cozy> part of how we'd like to do that is by relaying midi data from the acts themselves, as per my earlier post, via MIDI pickups, audio-MIDI vst's, and sensor data
<cozy> but it's really just in a logistics phase right now
<cozy> the people i'm working with used to use onadime, but that went proprietary a while ago
<cozy> so we'd like to have some of the functionality of that
<cozy> OK
<cozy> So what I'd like to know is WHERE do you write the patches
<cozy> The FNP's
<cozy> Do you have to set up the Milkymist One with a monitor and use a built in GUI?
<kristianpaul> yes
<kristianpaul> (monitor part)
<cozy> OK
<xiangfu> cozy, direct use Milkymist One with a monitor
<xiangfu> cozy, have you look this: http://youtu.be/7Qlb1cw_VKk
<cozy> Now what if we had either an emulated Milkymist or a testbed type machine running for creating new patches on the fly; can you upload that patch to the Milkymist One that is projecting via Ethernet? Or is the Ethernet more for something else?
<kristianpaul> using ethernet you get newest patches from the internet yes, if i undertood correctly
<xiangfu> cozy, for you. you can't just upload and performance a 'patches' to milkymist on the fly.
<kristianpaul> indeed
<cozy> ok
<cozy> i don't know why my buddy asked about that anyways
<cozy> i would think you'd want to be able to write and test patches well before they were to be used in a live context
<cozy> Thanks for that link xiangfu
<cozy> I'm assuming that you can map those controls that he's using to any MIDI event, am I right?
<xiangfu> cozy, http://www.youtube.com/watch?feature=player_embedded&v=ZcO3qslAmTo <--- here is small video that used milkymist in live show
<cozy> So for example, if you would like the color change when a MIDI note A 440hz is sent, you'd just have to map that?
<xiangfu> cozy, correct.
<cozy> That's what I figured
<cozy> I'm pretty sure a MMOne is going to do everything we'd like it to
<cozy> My buddy is skeptical
<cozy> Heh
<cozy> I'll convince him though
<cozy> We already have a bunch of projectors, but we've just been running GForce on one, and then I run GrandVJ on another
<cozy> And there's a couple others we haven't really done much with
<cozy> I actually saw that vid, it was posted on the main site I believe
<cozy> It doesn't look as if they have much audio/midi triggered stuff going on there, mostly just seemingly random stuff
<xiangfu> cozy, you may really want try the Live Video Synthesizer. :)
<cozy> Heh
<cozy> I do, I do!
<xiangfu> oh. yes and OSC from the Ethernet
<cozy> Cool
<xiangfu> cozy, I think they are use audio. but I don't know if they used a Line-In. or direct used MIC inside Milkymist one.
<cozy> k
<xiangfu> the Line-In is the best for pick-up/react to Sound.
<cozy> got it
<cozy> only an 1/8" jack though
<cozy> i suppose it doesn't need to be a really great audio signal to trigger events though
<xiangfu> this video is not very good. because I used too much convert and make the Video bad.
<cozy> So would it be possible to emulate the Milkymist Firmware/Flickernoise on a Linux machine, just to use as a testbed/patch writing setup?
<cozy> I know I can setup Ubuntu or Debian with a realtime kernel, and if need be get a pumped up video card in there
<cozy> not sure about the other components
<cozy> i.e. video effects... are the video effects in the milkymist one software or hardware?
<xiangfu> cozy, no. we can only test that the patch compile fine. but we can't test the REAL performance and what is look like
<cozy> that would be ok
<cozy> so then it is possible to emulate flickernoise in order to just test patches?
<cozy> but only on a linux install with a realtime kernel and a good video card?
<xiangfu> (just test patches) if you mean what the patches looks like. NO. we can emulate that in Linux.
<xiangfu> it's not about Video card and realtime kernel. there are some hardware core inside Milkymist One.
<cozy> you can emulate the patches in linux?
<xiangfu> no.
<cozy> so the only way to write and test FNP's is on the MMone itself?
<xiangfu> yes. I think so.
<kristianpaul> unless is a pattch that orginally came for Milkdrop
<kristianpaul> but latelly there are a growing set of features that just run on the Milkymist One, yes
<xiangfu> yes. but the real look like will be different under Milkymist One.
<kristianpaul> hmm yes,
<xiangfu> and for those OSC, Sound, MIDI, DMX, Live Video. really hardware to test under a emulate program.
<xiangfu> s/hardware/hard
<xiangfu> kristianpaul, (there are a growing set of features) correct.
<kristianpaul> MIDI is one of the coolest growing features !
<xiangfu> I think it's happening every week. :)
<kristianpaul> wpwrak: :)
<xiangfu> kristianpaul, yes. thanks to Werner.
<kristianpaul> plus friendlier patch language
<kristianpaul> and so on :)
<cozy> the patch language seems surprisingly straightforward
<kristianpaul> moving image support demos ;) http://downloads.qi-hardware.com/people/werner/m1/demo/wheel.ogv
<xiangfu> cozy, so you like it?
<kristianpaul> cozy: ^
<cozy> I do, from what I've seen
<cozy> Pretty exciting
<kristianpaul> you have DMX driven lights?
<xiangfu> cozy, great. we do want more feedbacks from VJ. :)
<kristianpaul> indeed
<xiangfu> cozy, you are running a pub ?
<xiangfu> cozy, or you are making devices and sell them?
<xiangfu> I may guess what you want make. it is just the Milkymist One :P
<cozy> xiangfu, we have a studio we're working out of
<cozy> but we're trying to open up another venue
<cozy> and yes, dmx lights
<xiangfu> cozy, MM one can used as DMX controller or DMX fixture.
<xiangfu> cozy, cool. in which city?
<kristianpaul> lekernel: what about i want to integrate some (<10) registers to csr bus generated from migen, is this still posible?
<kristianpaul> or better write that in the logic for the slave core anywya...
rejon has joined #milkymist
<kristianpaul> uart example is good, just that is it written all in migen/fhdl :)
<cozy> xiangfu, Scranton, Pennsylvania, USA
<kristianpaul> i guess i can base some tests from the m1crg that re-uses (instanciate) some verilog module
<kristianpaul> looks clean way of verilog <-> migen integration !!
<cladamw> wpwrak, a high side should use a P-MOSFET, like this: http://search.digikey.com/us/en/products/NCP380LSNAJAAT1G/NCP380LSNAJAAT1GOSTR-ND/
<cladamw> wpwrak, lekernel's two 1206s with 50 ohm idea to replace R143/47 Ohm but without short protection. It's a fact. It sustains only 0.1A at maximum. Which is bad that I don't have P-MOSFET now.
<cladamw> wpwrak, NCP380LSNAJAAT1GOSTR-ND @0.276USD/ea, I'm thinking directly use PTC @hold current=50mA, @trip current= 150mA, like Tyco p/n: MICROSMD005F-2, time to trip =1.5s, which is good to me, http://search.digikey.com/us/en/products/MICROSMD005F-2/MICROSMD005FTR-ND/
proppy has joined #milkymist
xiangfu has joined #milkymist
<hypermodern> xiangfu do you know Werner's email?
<xiangfu> hypermodern, what you mean?
<xiangfu> hypermodern, you mean email address?
<hypermodern> Yes.
<xiangfu> hypermodern, werner # almesberger.net
<hypermodern> Perfect
<hypermodern> thank you.
<hypermodern> Nice job on the video with the lights and lazers by the way
<xiangfu> :)
<xiangfu> be back later
azonenberg has joined #milkymist
cladamw has joined #milkymist
rejon has joined #milkymist
wolfspraul has joined #milkymist
<wpwrak> cozy: (developing patches) there's more than one way to do it :)
<wpwrak> cozy: there's also a native linux application that runs the patch compiler. i use it for regression tests, but you can also run it to syntax-check a patch. (flickernoise/src/compiler/ptest/)
<wpwrak> cozy: after that, you ftp it to the milkymist and have it running with a click or two. this isn't perfectly streamlined but i find it bearable. editing directly on the milkymist is an option, but whether it's comfortable depends on a number of things, including how your desk is arranged. e.g., it's very confusing to switch keyboards :)
<wpwrak> cozy: it's currently not possible to add patches to the active set while rendering. you can upload them such that they can be integrated later, though.
<wpwrak> cozy: whether it would be feasible to compile patches while rendering would have to be tested. i don't know to what extend the two would get into each other's hair when competing for resources.
<wpwrak> cozy: (the cpu core is kinda slow - one of the drawbacks of using an fpga)
<wpwrak> cladamw: (1206 with 50 Ohm) that would be 50 Ohm with 50 Ohm in parallel, yielding 25 Ohm ?
<wpwrak> cladamw: the problem with using resistors is that they drop the "5 V" voltage a lot at the nominal maximum of 50 mA. e.g., with 25 Ohm, you'd still drop by 1.25 V
<cladamw> wpwrak, forgot about my previous words, sorry, lekernel's idea was two * 1206 100 Ohm, so is 50 Ohm in parallel.
<wpwrak> cladamw: alas, your dvi specification doesn't say anything about the tolerance of the 5 V supply. but i guess it's probably not safe to assume you can vary by more than 10%. so that would be 500 mV -> 10 Ohm maximum
<wpwrak> of course, that in turn would limit the short-circuit current to 500 mA, burning a nice 2.5 W ...
<cladamw> wpwrak, i don't think that using resistors way to both limit current and short is good idea.
wolfspraul has joined #milkymist
<cladamw> i checked high-side P-MOSFET and N-MOSFET which is better but not cheapest way, also I checked about PTC idea again; the PTC idea is the middle-price and better for us now.
<wpwrak> cladamw: yeah. unless we decide to deliberately violate the specs, i don't see plain resistors as a viable approach
<wpwrak> cladamw: i don't have hands-on experience with PTCs. but yes, they sound suitable for solving that problem.
<cladamw> wpwrak, i'm writing email to reply last one. stay tuned. but comments when you see it, thanks in advance.
<cladamw> wpwrak, yeah...but it's okay, I'll link you to see those spec page on PTC, so you'd easily know it. :-)
<wpwrak> (data sheet) yeah, but that doesn't tell me all the things i don't know :) e.g., what are Rmin and Rmax ? Rmin = 3.6 Ohm sounds great if that's the resistance at 50 mA. but then, what it Rmax = 50 Ohm ? it would be okay as the short-circuit current (250 mW, but the chip is rated at 1 W, so we'd just have to make sure it doesn't cook anything in the vicinity)
<wpwrak> but ... looking at the Rmax values of other parts, this doesn't seem to be the short-circuit resistance. and if it means that Rmax is reached at Ih, then that wouldn't be so good.
<wpwrak> so, again, my (lack of) knowledge of PTCs doesn't let me evaluate that proposal properly
<cladamw> aha...okay, pls see Figure 8 in page 127 of that long spec link first...;-)
<Fallenou> 02:58 < cozy> Do you have to set up the Milkymist One with a monitor and use a built in GUI? < you can do it on a normal computer and then upload it to M1 via ftp
<wpwrak> cladamw: err, which document ? i'm looking at the polyswitch from te (which isn't a ptc anyway :), but that only has 20 pages
<cladamw> wpwrak, the 20 page is correct too, see page 12
<cladamw> wpwrak, sorry, page 13, Figure S8
<wpwrak> that document has only 13 pages and no figures on the last one :)
<wpwrak> but page 5 is a bit unsettling
<cladamw> see page 13. :-)
<wpwrak> ah, the 20 page document. AAAH ! now is see why you say "page 127" :)
<wpwrak> yes, but that only lists the trip current
<cladamw> see it? ah..sorry
xiangfu has joined #milkymist
<wpwrak> according to the 13 page document, section "Reflow and Trip Jump (Rimax)", the resistance increases after the first upset, and may stay higher for years
<cladamw> yes, better than resistor solution at least. ;-)
<wpwrak> according to the 20 page document, if Rmax means Rimax, the component in question could go as high as 50 Ohm
<wpwrak> so this means that this fuse may only be good for one short. afterwards, we'd be back to the 50 Ohm-is-too-much situation
<cladamw> let's see introduction pdf : Fundamentals of PolySwitch Overcurrent and Overtemperature Devices
<cladamw> see page 12 for "Selection steps from the CatalogStep", i need also check it again. ;-)
<wpwrak> ah, ther they define
<wpwrak> the mapping
<wpwrak> so Rimax -> Ri
<wpwrak> and Rmax is really just the regular resistance, even without tripping
<wpwrak> but i guess it may include Rimax. at least i don't see Ri anywhere in the 20 pages document
xiangfu has joined #milkymist
<wpwrak> so my interpretation is that the polyfuse will have a resistance of 3.6 Ohm <= R <= 50 Ohm with current |I| <= 50 mA, with a history that includes zero or more trips.
<cladamw> when PTC trips means current being blocked though since high themal resistance already,
<cladamw> s/though/through
<wpwrak> yes, but Rmax is still in the un-tripped state. 13 page document, last page: "the maximum resistance prior to the trip of PolySwitch device"
<cladamw> yes
<cladamw> he, not Rimax, they call "R1"
<wpwrak> ah right, R1 (page 13) or R1max (page 5)
wolfspraul has joined #milkymist
<cladamw> let's follow its steps. :-)
<cladamw> Normal operating current: less than 10mA ( when compliant DVI monitor is ON ), this determines in dvi-10.pdf and should not drew 50mA (when DVI monitor is OFF), i.e. DDC power supplys from monitor's internal circuit EEprom itself 5V. correct? ;-)
<cladamw> but host needs at least 55mA to supply monitor.
<wpwrak> yes
<cladamw> we can say this to be even said a 10mA limit as "Normal operating current", isn't?
<cladamw> "Maximum interrupt current" --> 50mA
<cladamw> "Maximum operating voltage" --> more than 5V, said 6V or more
<cladamw> "Maximum ambient operating temperature" --> 70
<cladamw> step one is okay?
<lekernel> hypermodern: the full resolution of these pictures is 640x480
<lekernel> for most of them
<wpwrak> i think it should be maximum hold current, no ? i interpret hold/trip current as "I =< hold -> it's guaranteed not to trop. I >= trip -> it's guaranteed to trip. hold < I < trip -> ???"
<lekernel> there are a few 1024x768
<lekernel> wpwrak: what about relying simply on the main PTC instead of adding more and more stuff to this poor board?
<cladamw> wpwrak, agreed, but from hold Current (A) at Ambient Temperature (oC)] , you can only see their small 50mA for hold current.
<cladamw> lekernel, no. Be noted that although M1 have 2A PTC on 5V path already, keeping DDC 5V tripped prior to the protection of whole DC power in is must if using this way. From Figure S8 curve A, a fault current 1A can let PTC tripped within 50ms.
<cladamw> lekernel, we at least need DVI DDC short case to be trip prior to whole M1 2A PTC.
<lekernel> M1 will be the most rugged board on earth :) I bet R5 will be able to accept mains in any connector *g*
<wpwrak> lekernel: that trips at a much higher current, doesn't it ? but yes, it may be an option. it would mean that an overcurrent situation with a resistance of about 1-5 Ohm might fry the DVI connector. < 1 Ohm and it will trip the PTC. > 5 Ohm and the current will be within the connector rating (1 A, if i remember correctly)
<wpwrak> lekernel: only mains ? what about lightning strike directly in the middle of the board ? :)
<cladamw> if we use like 50mA hold PTC, it needs 1.5s to trip when get 0.15A. But actually if it DDC shorts, it trip immediately.
<cladamw> off course if we use resistors for limit. This assumes for short current at 100 mA, this two * 1206/100 Ohm would reach rated power at 70°C is 1/4 W. Insensitive one could not smell short occurs up and resistors get aged. Even PCB surface is still good. Of course shorting on DDC is extremely few chance in the end.
<cladamw> Cheapest way(0.022 USD/10pcs), not resetable, but no guarantee though. ;-)
<wpwrak> and DDC5V = 2.5 V @ 50 mA
<wpwrak> if you want to go that route, you have to have an R143 equivalence of 10 Ohm (for DDC5V(min) = 4.5 V)
<cladamw> correct ! so i measured voltage drop on R143 in rc3, DDC voltage to monitor almost stay the same. (i.e. DDC 5V surge very few current in vga DDC eeprom circuit)
<wpwrak> so you're saying that there are no monitors/projectors/etc. that actually draw nearly the full 50 mA ?
<cladamw> this quite explains dvi_10.pdf says a 10mA (when monitor is ON), drop is only 0.47 V at maximum. (if monitor is in spec.)
<cladamw> wpwrak, no
<wpwrak> so, what's the conclusion then ? :) how big shall R143 be ?
<cladamw> so I don't think a monitor will surge much current even over 10mA.
<cladamw> well...now we try to determine R143 is because we're considering a 'short'. so PTC is definitely can handle this. just to find a suitable one. ;-)
<wpwrak> (DCC5V current) yes, i also don't expect that monitors will rely heavily on this. but then, i don't _know_ ...
<cladamw> no bead, no real resistor for R143, since now we're thinking a 'short' case, if we ignore 'short' (extremely few chance), we use resistor.
<xiangfu> lekernel, just sent out a new patch about video parameters. :)
<cladamw> yeah, me also don't know. but at least a PTC should handle this. at least 0.37 USD/ea.
<cladamw> if using high-side current limit, it costs about 0.84 USD/ea.
<wpwrak> 0.305 @ 100 units, 0.205 @ 1000. the 1 piece prices can be hopelessly inflated.
<wpwrak> (that's for the PTC)
<cladamw> yup
<cladamw> inflated a bit from me. ;-)
<cladamw> but from Digikey. :)
<wpwrak> 300 mW is cutting it a bit close, though
<cladamw> want to use a PNP transistor?
<wpwrak> it should work. at least in theory :)
<wpwrak> not sure how precise the current amplification ratio is, though
<cladamw> if short occurs, how's your resistance?
<wpwrak> i only know my current, Ice = Ib*hfe ;-)
<wpwrak> resistance is futile :)
<wpwrak> what's not so nice is that it doesn't cut off on undervoltage. so if R2 = 0, it happily burns 250 mW
<cladamw> oah..yup. that link you did already.
<hypermodern> xiangfu I made a remix http://youtu.be/TktemIMmSB0
<xiangfu> interesting.
<wpwrak> ;-)
<wpwrak> have you tried the buttons to change the images ?
<xiangfu> wpwrak, not yet. that is the plan. can't wait try them.
<wpwrak> i was thinking of making a video with the sad story of the ghost, but couldn't find an overly good narrative
<xiangfu> wpwrak, the vga parameters bug fixed. wait lekernel review. then I will commit it.
<xiangfu> wpwrak, after fix the vga bug. I tried the showwx+ to project to my room wall. and floor. really cool.
<wpwrak> vga is cool let's hope this doesn't break anything. parameter changes are always tricky.
<wpwrak> hehe ;-)
<xiangfu> wpwrak, if we have a vga projector ball. like a 6 projector. that will be great.
<lekernel> xiangfu: yes, go ahead with the parameter change
<xiangfu> lekernel, I mean the new one. also changed on 1024x768 and 800x600
<xiangfu> wpwrak, people would like to just stand in that room :D
<wpwrak> and drool ;-)
<cladamw> wpwrak, so you'd rather select transistor than a PTC?
<lekernel> xiangfu: yes, go ahead. I just found those values from some internet sources, tested them on my monitor, and that's all.
<lekernel> all it does is make the vsync pulses a bit longer/shorter
<lekernel> does it still work on your other screens?
<xiangfu> lekernel, yes. works fine on other screen. (but I only have one)
<GitHub127> [milkymist] xiangfu pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/71f9ba51bda9e4868bff53af08b464aad9809ac2
<GitHub127> [milkymist/master] VGA: fix the vsync pulses - Xiangfu Liu
guyzmo has joined #milkymist
<wpwrak> cladamw: if you can find a ptc that works, the ptc may be easier
<cladamw> wpwrak, i'll try even order some if needs.
<xiangfu> rtems patch email one vga sent out
guyzmo has joined #milkymist
elldekaa has joined #milkymist
rejon has joined #milkymist
wolfspraul has joined #milkymist
cladamw has joined #milkymist
xiangfu has joined #milkymist
elldekaa has joined #milkymist
antgreen has joined #milkymist
netru has joined #milkymist
VJTachyon has joined #milkymist
<cozy> Fallenou, how would one go about doing that? Is there a way to set up Flickernoise on a standard Linux installation, or what..?
<Fallenou> Flickernoise runs on the M1
<Fallenou> you can emulate the M1 and run parts or Flickernoise on a PC using Qemu
<Fallenou> I don't know if Qemu is still up to date
<cozy> Ahhh
<Hodapp> Fallenou: What is performance like for something like this?
<Hodapp> Good enough to use, or just good enough for the sake of testing?
<cozy> Good question
<Fallenou> But IIRC tmu is not up to date so you would not be able to do rendering stuff on Qemu
<Hodapp> tmu?
<Fallenou> just use the GUI
<cozy> You could just write patches
<Fallenou> Hodapp: texture mapping unit
<Hodapp> I was curious about something similar, but I guess it's rather tough to make it work similarly on a PC with all that custom hardware
<Hodapp> though I'd like to at least play with some MilkDrop patches (or some Linux-equivalent)
<Fallenou> I think you can only run the "patch development and patch selection / settings" part of Flickernoise on qemu for now
<Fallenou> but not the performance mode
<Fallenou> cozy: what I said earlier is that you can develop your patch on your PC since it's only text files, so you can do it using whatever text editor you like (gedit vim emacs etc)
<Fallenou> and then when you're done you upload it on your M1 via FTP
<cozy> Ahhh
<Fallenou> that's what I meant
<cozy> Got it
<Fallenou> sorry if I mislead you :)
<Hodapp> wonder if anybody in the Cincinnati area has an M1. I suppose I could be the first...
<cozy> So no way as of yet to emulate performance mode reliably, but Flickernoise can be emulated just for writing patches, or you can write 'em in a text editor
<Hodapp> haven't met many local VJs though, and I'm really not one
<Fallenou> cozy: I think performance mode used to work on qemu, with previous tmu (kind of gpu inside M1 SOC), but now it's tmu2 and it hasn't been updated in qemu
<Fallenou> afaik
<Fallenou> so it won't work
<cozy> What if I were to get that earlier version?
<cozy> Is that still available in repos or something?
<Fallenou> well it could work I guess, to try to use an old bios + flickernoise version with qemu
<cozy> Yeah
<Hodapp> Is QEMU fairly well still the standard for embedded system emulation?
<Fallenou> try to find the last commit containing tmu version 1
<Fallenou> Hodapp: qemu is quite a nice piece of software yes :)
<Hodapp> I remember seeing a talk about this 3-4 years ago at Ohio LinuxFest
<Fallenou> it's a creation of Fabrice Bellard it must be good :p
<Hodapp> speaker talked about how it was often a much more viable solution to build an entire environment inside QEMU, including full build toolchain, than to try to do all testing on real hardware (which in some cases was not even possible) or to try to do everything with cross-compiling
<Hodapp> He pointed out some features I was not aware of, like the ability to talk to a QEMU virtual machine via stdin/stdout from your perspective, serial in/out from the VM's perspective
<Fallenou> there is a lot of nice features in qemu/kvm
<Fallenou> including virtio :)
<cozy> Fallenou, can one upload a patch via FTP to the M1 while the M1 is running in performance mode?
<Fallenou> usb passthrough, pci passthrough, networking etc
<Fallenou> cozy: I think yes, I don't know if it can have impatch on performance FPS
<Hodapp> It's been awhile since I've used it; I mostly use VirtualBox now. But that's hardly comparable when I only emulate x86 at the moment.
<lekernel> cozy: yes, that works
<Fallenou> but you would not be able to add the patch to the batch being performed
<Fallenou> you would have to stop the performance, then add your patch to the batch, and relunch the perf'
<Fallenou> relaunch*
<lekernel> yes
<Fallenou> I wonder if "live adding a new patch" is really an important use case
<cozy> I think it would be
<Fallenou> since you are busy VJing you can't be editing a new patch
<Fallenou> or maybe you are a VJ team
<cozy> Especially if you're trying to create patches that would be reacting to MIDI note input
<cozy> Waves based upon frequencies, etc.
<Fallenou> if you are creating then you're not in performance mode, right ?
<Fallenou> you are editing (on the M1 ?), you want to give it a try : you run performance mode. Then you go back to editing mode etc
<cozy> But what if you want a wave based on the frequency of a particular note?
<cozy> We're looking to trigger M1's via MIDI notes from hexaphonic pickups
<cozy> For effects, etc., that could be fine, for particular patches
<Fallenou> I think you can do this but I'm no expert on MIDI stuff
<cozy> I suppose we could just write 144 different patches
<Fallenou> I think there is some kind of misunderstanding here
<Fallenou> if you want your M1 to react according to specific MIDI event
<Fallenou> you can just write it inside the patch I guess
<Fallenou> there must be a FNP "command"/"instruction" for this
<Fallenou> I'm not up to date about FNP language sorry
<Hodapp> FNP?
<cozy> no worries
<cozy> flickernoise patch
<cozy> thank you, Fallenou, very helpful
<Fallenou> you're welcome !
<Fallenou> you can ask wpwrak about midi stuff I think
lekernel_ has joined #milkymist
<LmAt> mik
<GitHub112> [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/usSk0A
<GitHub112> [milkymist-ng/master] s6ddrphy: read path OK in simulation - Sebastien Bourdeauducq
rejon has joined #milkymist
kilae has joined #milkymist
elldekaa has joined #milkymist
<wpwrak> (midi) yup :)
<cozy> I'm gonna piece through the LaTex manual and then hopefully I'll have a better idea of how to implement what I'd like to
<wpwrak> yeah, it should give you some ideas. it's not a tutorial, though. quite a lot of things aren't obvious.
<cozy> hmm
<cozy> any good tuts out there?
<wpwrak> not yet ...
<wpwrak> if you google for milkdrop, you can find some material that largely applies
<Hodapp> Is projectM any good for being MilkDrop-compatible?
<wpwrak> i don't know. milkdrop compatibility should help, since flickernoise is compatible with a subset of milkdrop (and then has some extensions on top of it)
<lekernel> Hodapp: yes, projectM is quite good at running MD presets
<Hodapp> course, I assume I don't get things like MIDI input or video input there
<wpwrak> (midi documentation) here's how it currently works: http://downloads.qi-hardware.com/people/werner/m1/tmp/midi-draft-20120215.pdf
<wpwrak> if qemu can only run the GUI, there's little point in bothering with it. if all you get is the patch compiler, it's just as easy to run ptest on the patch.
<wpwrak> ptest -c -q <patchfile
<wpwrak> if there's no output, compilation was successful. else, there will be a complaint
<kristianpaul> lekernel: from where you get the milkymist libc?
<kristianpaul> linux?
<larsc> kristianpaul: it's newlib iirc
<kristianpaul> oh really?
<kristianpaul> oh
antgreen has joined #milkymist
elldekaa has joined #milkymist
stekern has joined #milkymist
stekern has joined #milkymist