<kristianpaul>
:D SD_CLK A10 IO_L34N_GCLK18, just that i needed :)
<kristianpaul>
s/that/what
<kristianpaul>
ah, well, i could get a GCLK from the H/W Control
<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.
<wpwrak>
this would mean a departure from milkdrop compatibility, at least in the M1 -> MD direction. not sure if this is a problem ?
<lekernel_>
MD doesn't support MIDI, so no
<lekernel_>
but I don't get what you mean with "array"
<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 ?
<lekernel_>
from my understanding it's already an "array" and it has nothing do to with variable scaling
<lekernel_>
or you mean a LUT?
<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]
<wpwrak>
yes
<lekernel_>
then yes, that's a possible optimization
<lekernel_>
but it stays 100% compatible with the current system, no?
<wpwrak>
forward-compatible :)
<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
<lekernel_>
but I'm not even sure that MIDI conversion puts anything else than a negligible load on the CPU
<lekernel_>
before jumping to implementations, could we do some profiling?
<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
<lekernel_>
as far as I can see, the main candidates for optimizations are wave drawing and audio analysis
<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
<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
<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)
<lekernel_>
never had such a bug with my setup... Murphy's law striking again
<wpwrak>
yeah, the joy of a growing user base :)
<wolfspra1l>
wpwrak: are you connecting your kaossilator pro to the m1 directly via midi, or via pc?
<wolfspra1l>
I thought the 'pro' had a direct (old) midi-out line, no?
<wpwrak>
saturday, via midi. now via pc.
<wolfspra1l>
why via pc now?
<wpwrak>
to work around a limitation of the kaossilator :)
<wpwrak>
just a sec. demo video coming ... i hope
<wpwrak>
okay, uploading
<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
<wpwrak>
so i did all the MIDI interconnects on the PC
<wpwrak>
(sharing) i.e., passing MIDI data through
<wpwrak>
wolfspra1l: have you pinged faderfox ?
<kristianpaul>
ha, catch it when you dont use ethernet the phy_rst_n signal needs to be "driven" somwhere :)
<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.
<lekernel_>
no, but I don't see a practical application for this (yet)
<wpwrak>
as i said, overlapping controller numbers
<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 :)
<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.
<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 ?
<wpwrak>
s/changed/changes/
<kristianpaul>
jsut 10 minutos to sinthesize a very basi m1 soc nice :)
<wpwrak>
it's almost getting useful ;-)
<wpwrak>
well, s/useful/usable/ :)
<lekernel_>
yes
<lekernel_>
what is getting usable?
<wpwrak>
synthesis. with only 10 minutes of coffee break :)
<lekernel_>
phew, it's already much better than many other ASIC and FPGA SoC's