<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?
<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
<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?
<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.
<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
<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
<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.
<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>
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?