| kristianpaul | :D SD_CLK A10 IO_L34N_GCLK18, just that i needed :) | 04:03 |
|---|---|---|
| kristianpaul | s/that/what | 04:06 |
| kristianpaul | ah, well, i could get a GCLK from the H/W Control | 04:09 |
| wpwrak | lekernel_: a few ideas: to support lots of controls, it may be useful to do the MIDI value -> midiX variable value mapping with an array. that should be easier on the CPU than division and it would also allow for all kinds of application-specific mappings, e.g., a exponential/logarithmic curve, discrete values, [0, 127] -> [-1, 1], etc. | 09:31 |
| wpwrak | this would mean a departure from milkdrop compatibility, at least in the M1 -> MD direction. not sure if this is a problem ? | 09:32 |
| lekernel_ | MD doesn't support MIDI, so no | 09:34 |
| lekernel_ | but I don't get what you mean with "array" | 09:34 |
| wpwrak | then, it ocurred to me that the pixel FPU we discussed a while ago for camera input could also be placed in the video out path. could this make sense ? | 09:34 |
| lekernel_ | from my understanding it's already an "array" and it has nothing do to with variable scaling | 09:34 |
| lekernel_ | or you mean a LUT? | 09:35 |
| wpwrak | instead of, calculating midiN from the [0, 127] value on each reception, you'd have a pre-computed float [127] array and just do midiX = midiXarray[received_value] | 09:35 |
| wpwrak | yes | 09:35 |
| lekernel_ | then yes, that's a possible optimization | 09:35 |
| lekernel_ | but it stays 100% compatible with the current system, no? | 09:36 |
| wpwrak | forward-compatible :) | 09:36 |
| wpwrak | i think it would be useful to have means in the patch language to define such mappings. that could be done in a way that defaults to the existing behaviour if you don't do anything | 09:37 |
| lekernel_ | but I'm not even sure that MIDI conversion puts anything else than a negligible load on the CPU | 09:37 |
| lekernel_ | before jumping to implementations, could we do some profiling? | 09:37 |
| wpwrak | yes, the division is probably harmless. but if you want more complicated curves, you may have to do a lot math in the GPU | 09:38 |
| lekernel_ | as far as I can see, the main candidates for optimizations are wave drawing and audio analysis | 09:38 |
| lekernel_ | those areas are where the CPU spends most of its time in, so any optimization there has way more potential than in something that uses < 1% of the CPU time | 09:39 |
| wpwrak | also things like compensating for hardware imperfections. e.g., if you want a slider that goes exactly from 0 to 1, but your sliders give you values from 6 to 123, then you'll want to do something like f = max(min(123, (v-6)/117), 0); which is kinda wasteful | 09:40 |
| wpwrak | btw, i'm getting the MIDI lags again. i'm also losing values quite often, but i don't know where. (controller, path through pc, or m1) | 10:20 |
| lekernel_ | never had such a bug with my setup... Murphy's law striking again | 10:26 |
| wpwrak | yeah, the joy of a growing user base :) | 10:31 |
| wolfspra1l | wpwrak: are you connecting your kaossilator pro to the m1 directly via midi, or via pc? | 11:06 |
| wolfspra1l | I thought the 'pro' had a direct (old) midi-out line, no? | 11:06 |
| wpwrak | saturday, via midi. now via pc. | 11:07 |
| wolfspra1l | why via pc now? | 11:10 |
| wpwrak | to work around a limitation of the kaossilator :) | 11:17 |
| wpwrak | just a sec. demo video coming ... i hope | 11:18 |
| wpwrak | okay, uploading | 11:24 |
| wpwrak | the problem is that the kaossilator seems to be reluctant on the MIDI in side. it does receive some things, turns deaf to others, and really really hates sharing | 11:25 |
| wpwrak | so i did all the MIDI interconnects on the PC | 11:25 |
| wpwrak | (sharing) i.e., passing MIDI data through | 11:26 |
| wpwrak | wolfspra1l: have you pinged faderfox ? | 11:28 |
| kristianpaul | ha, catch it when you dont use ethernet the phy_rst_n signal needs to be "driven" somwhere :) | 11:36 |
| wpwrak | lekernel_: btw, is there anything that would speak against having M1 listen on multiple MIDI channels ? that would make it easier to hook up MIDI devices with overlapping controller numbers. | 11:36 |
| lekernel_ | no, but I don't see a practical application for this (yet) | 11:36 |
| wpwrak | as i said, overlapping controller numbers | 11:37 |
| wpwrak | e.g., my kaossilator has some buttons overlap with the nanoKONTROL2. right now, i just don't use these buttons. (we currently have far too few controls in FN for such luxury anyway :) | 11:38 |
| wpwrak | and if i had to use them, i could reassign them. but that's painful. things like MIDI (or DMX) devices aren't exactly famous for their easy setup. | 11:39 |
| wpwrak | ah, and patch selection is currently only with notes, correct ? i.e., to use buttons that act as controllers (and not as a piano), some code changed would be needed ? | 11:40 |
| wpwrak | s/changed/changes/ | 11:40 |
| kristianpaul | jsut 10 minutos to sinthesize a very basi m1 soc nice :) | 11:48 |
| wpwrak | it's almost getting useful ;-) | 11:48 |
| wpwrak | well, s/useful/usable/ :) | 11:52 |
| lekernel_ | yes | 11:53 |
| lekernel_ | what is getting usable? | 11:53 |
| wpwrak | synthesis. with only 10 minutes of coffee break :) | 11:56 |
| lekernel_ | phew, it's already much better than many other ASIC and FPGA SoC's | 12:10 |
| wpwrak | http://downloads.qi-hardware.com/people/werner/m1/demo/MVI_1747.MOV | 13:49 |
| wpwrak | wolfspraul: http://downloads.qi-hardware.com/people/werner/m1/demo/MVI_1747.MOV | 14:04 |
| wolfspraul | wpwrak: so the faderfox LV3 would not work with M1 today, right? | 14:28 |
| wolfspraul | we would need to implement usb-midi, and make it work well with our patches | 14:28 |
| wpwrak | it wouldn't work without a PC in the middle | 14:31 |
| wolfspraul | yeah | 14:31 |
| wpwrak | but sebastien plans to implement usb-midi soonish | 14:31 |
| wolfspraul | ok, sent my first heads up to faderfox | 14:37 |
| wolfspraul | if I hear nothing, will send another one in 1 week, etc. | 14:37 |
| wolfspraul | wpwrak: thanks for reminding :-) I need some more discipline to contact 10 potential business partners/opportunities per day ;-) | 14:38 |
| wpwrak | ;-)) | 14:38 |
| wpwrak | what did you write to him ? | 14:38 |
| wolfspraul | we have a long and messy list, and with all the leads we have now we could even easily grow the list http://en.qi-hardware.com/wiki/Milkymist_One_marketing#Links_to_Communities.2C_Companies.2C_Projects.2C_Technologies | 14:38 |
| wolfspraul | just saying hello | 14:38 |
| wolfspraul | pointing to m1 | 14:38 |
| wpwrak | hmm, "spam" ? | 14:38 |
| wolfspraul | nah | 14:39 |
| wolfspraul | no way | 14:39 |
| wolfspraul | I write a meaningful text, I mean we have to start somewhere, right | 14:39 |
| wolfspraul | he seems to like to integrate his products, "works with Ableton Live" | 14:39 |
| wolfspraul | that's good | 14:39 |
| wolfspraul | so let's see, one by one | 14:40 |
| wpwrak | so what were the actionable items in your mail ? a question perhaps ? | 14:40 |
| wpwrak | (integrate) everybody does that | 14:40 |
| wolfspraul | the action item for him is to go to https://sharism.cc/milkymist | 14:40 |
| wolfspraul | meanwhile I will read some more about the LV3 too | 14:40 |
| wpwrak | all the controllers have whole libraries of profiles, plugins, etc. of course, all for proprietary stuff | 14:40 |
| wolfspraul | he may or may not be interested in such a contact, I don't know | 14:41 |
| wolfspraul | anyway | 14:41 |
| wolfspraul | communication started | 14:41 |
| wolfspraul | I need to do 10 per day | 14:41 |
| wpwrak | (contact) it seems a bit vague. but okay, let's see what he says | 14:41 |
| --- Tue Nov 1 2011 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!