<xiangfu_>
yes. add some lines to function 'pfv_from_name'
<wpwrak>
or  ang=rot  in the patch ?
<wpwrak>
(or just s/ang/rot/ ;-)
<xiangfu_>
(ang=rot) should works fine.
<n0carri3r>
ahh OK cool
<wpwrak>
hmm, using  pld readreg  makes a later reconfig into standby hang. grmbl. in fact, it seems to prevent anything using IPROG (from the M1) from succeeding. jtag still works, though, including jtag-boot
<n0carri3r>
yeah, most of the simple patches (especially geiss ones) work with little or no changes
<xiangfu_>
we can add one line "if(strcmp(name, "ang") == 0) return pfv_rot;" to 'compiler.c'
<wpwrak>
but it seems that BOOTSTS isn't useful as an indicator of how we got into the standby bitstream
<wpwrak>
n0carri3r: so patches using "ang" look good if you use "rot" instead ?
<n0carri3r>
gonna find one
<n0carri3r>
one moment
<n0carri3r>
hmmm tried one now
<n0carri3r>
doesnt seem to display much
<n0carri3r>
i tried Luz by Geiss
<n0carri3r>
hmm, its also ignoring fRating
<n0carri3r>
that could be an issue
<n0carri3r>
wait, is that just a rating system? haha
<n0carri3r>
i realized a lot of these presets i copied used shaders
<n0carri3r>
i'm gonna go back and grab older milkdrop presets, which should be less complex and have higher compatibility
<n0carri3r>
i'll make FNP copies of any of the ones that look cool and work well
<n0carri3r>
i already found about 10 or 12
<n0carri3r>
i'll be back soon to chat
<n0carri3r>
have a nice night, guys!
<kristianpaul>
n8
<wpwrak>
wolfspraul: you just missed one of our first real users
<wolfspraul>
he
<wolfspraul>
I always sense some sarcasm in what you say :-)
<wpwrak>
naw, no sarcarsm. at least not this time ;-) a VJ who tried a few new patches.
<wpwrak>
promptly found a bunch of unimplemented features.
<wpwrak>
some sound hard to do. others less so.
<wolfspraul>
aha, nice
<wpwrak>
apparently, there are some 500 patches out there, of which quite a few should run on the M1. someone should go through them and classify them ... (well, perhaps this VJ will just do that)
<wolfspraul>
oh I know
<wpwrak>
(classify) as in whether they work and if not, why not. so far, missing things include variable called "ang" (dunno what it is - may be related to "rot"), a random number generator via the variable "rand", and shaders. the latter probably aren't so easy to have.
<wolfspraul>
ok great we get feedback, very happy about that
<wpwrak>
that 500+ potential patch repository may also change the marketing message a bit. it's not that we currently have ~50 patches and there could be more, but that we're already sitting on a goldmine we've barely begun to exploit.
<wpwrak>
(feedback) yes ! real user feedback !
<wpwrak>
meanwhile, i'm precision-measuring the work of my air conditioning :)
<kristianpaul>
networking setup ran "smooth"
<wpwrak>
very, yes. i was afraid he(?) would get stuck there
<kristianpaul>
yeah
<wolfspraul>
I am aware of the old patches
<kristianpaul>
afortuably its router was there
<wolfspraul>
but it's work to port more to m1, which we are aware of but it's somewhere in the 100+ items todo list
<wpwrak>
well, it seems some just need testing
<wpwrak>
should be fun to FFT the temperature curve, with the clean swings from the air conditioning
<kristianpaul>
plus a curve of humidity?
<wpwrak>
how many bench meters do you think i have ? ;-)
<kristianpaul>
well .. :)
<wpwrak>
but yes, one more measurement would be possible. but then i'd feel a little naked in my lab, with all the instruments in the guest room
<kristianpaul>
haha
<wpwrak>
the meter i'm using has a multiplexer card. but that probably doesn't work with a thermocouple
<kristianpaul>
for having usb connectivy i hope fancy features :)
<wpwrak>
the other one has ethernet :)
<wpwrak>
and my function generator even has a little web server :)
<wpwrak>
kristianpaul: it's not connected to anything, so you can't break anything by generating weird signals
<kristianpaul>
lets see
<wpwrak>
it didn't like that :)
<kristianpaul>
haha
<wpwrak>
hmm, is it stuck ?
<kristianpaul>
yeap
<wpwrak>
i see the forwarding complain
<wpwrak>
let's see
<wpwrak>
no, should be fine
<kristianpaul>
gone again
<kristianpaul>
anyway,looks very nice
<wpwrak>
i wonder where these intermittent failures come from. i made the port forwarding with ssh. it complains  connect_to fg port 80: failed.  ("fg" is the host name)
<kristianpaul>
ssh :o
<kristianpaul>
tun?
<wpwrak>
ssh -R :)
<wpwrak>
let's see if you've found the self-destruct button ... no, not yet :)
<kristianpaul>
lol
<wpwrak>
you're not outputting a signal. but i think the level is very low
<wpwrak>
s/not/now/
<wpwrak>
that's the DC offset
<wpwrak>
and no, you can't electrocute me so easily ;-)
<kristianpaul>
i'm done
<wpwrak>
turning the critter off again
<wpwrak>
pity my other instruments aren't web-enabled
<wpwrak>
meanwhile .... verified that BOOTSTS does reliably indicate whether standby booted or not. alas, it doesn't help with the other question we have, i.e., whether we came from power up or from a sw reboot
<sb0>
(blank patch) good idea. I was also thinking of a small 'keyboard panel' pop-up in the patch editor, with buttons that insert variable names when clicked on
<sb0>
this way we can even edit patches with the mouse alone
<sb0>
and no, ang is not supported... ideally, need to find a nice hack to implement atan2() on the FPGA with few resources
<sb0>
or a good-enough approximation of it
<sb0>
xiangfu, ang != rot
<sb0>
actually, if we are to improve the renderer, implementing this thing would indeed support many new interesting MilkDrop patches
<sb0>
other important missing features are custom waves/shapes and draw the waves with more points
<sb0>
using more points is just a value to change, but it makes things slow atm
<sb0>
and contrary to what the USB people usually write, it's not even several hundred pages long... maybe getting this stuff to work is simpler than I thought
<wpwrak>
sb0: do you think of extending the FPU instruction set for new things (e.g., the atan2) ? or would new things have to fit into the existing set ?
<sb0>
we can extend it
<sb0>
unless we come up with a decent approximation of atan2() using the current operations
<wpwrak>
good. there a bunch of spare bits :) pity that they're not enough to get rid of the hard-coded register in IF
<sb0>
note that it should take two parameters (x/y coords) and handle the four quadrants (it's not just arctangent)
<sb0>
the hard coded register is not only a problem of instruction set, it's also a problem of register file bandwidth
<sb0>
there are only two read ports on the register file
<sb0>
it's SRAM
<wpwrak>
the usual approach is to do a small bit of the range by the approximator and the rest in software
<sb0>
and the IF register is overlaid with flip flops, which can be read at any time
<sb0>
(it's just more FPGA routing)
<sb0>
there are few IFs anyway, and the IFs are slow
<sb0>
so this solution is acceptable
<wpwrak>
(read ports) hmm. change IF semantics to if (reg_in1) reg_out = reg_in2; ?
<wpwrak>
of course, this would create another write-write dependency, which may not be so good
<sb0>
why?
<sb0>
what's the problem with the current solution?
<wpwrak>
all the fixed registers create write-write dependencies, and R0002 sees a lot of reuse. a pure SSA design should give the scheduler more flexibility.
<wpwrak>
not sure if it would result in significant output improvements, though. would have to simulate
<sb0>
it's a bit similar to e.g. the zero flag on some microprocessors
<sb0>
well, the PFPU isn't the bottleneck
<wpwrak>
yes. also flags are anti-SSA :)
<wpwrak>
not yet ;-)
<wpwrak>
seems that we only have the simpler patches this far. there appear to be bigger ones just beyond the horizon.
<sb0>
if you are looking for optimizations, current candidates are texturing (very difficult) and graphics primitive drawing in software (easier and more classic)
<sb0>
also, FIR filtering of the incoming audio use a tad of CPU power too
<wpwrak>
the primitives would still be in the FPU ? or in the LM32 ?
<sb0>
some 20-30%
<sb0>
all the primitives are drawn in software, using (mostly) integer arithmetic
<sb0>
btw you can use 'cpustats' on the RTEMS shell to get the CPU time breakdown per task
<wpwrak>
(primitives) okay, that shouldn't be to hard. plenty of prior art to work from :)
<wpwrak>
btw, i have my sights set on the parser. if we add a lot of patches, it will become the next bottleneck. also, the language design sucks. how open are you to syntax changes that allow milkdrop patches still to be parsed but also a cleaner syntax for m1 patches ? (which milkdrop wouldn't understand. well, unless they implement it too)
<sb0>
mh? what's the problem with parsing milkdrop patches?
<wpwrak>
e.g., split things into sections. global, frame, vertex. without repeating for each equation where it goes.
<sb0>
I have already added some simplifications compared to MD, like making equation numbers optional
<sb0>
oh yes, sure, we can do that
<wpwrak>
great. i think that would make things a lot less intimidating :)
<wpwrak>
the other thing are all those strcmps. but getting rid of them properly will need some rewriting. also a lot of the parser could probably be initialized only once at boot time and then be kept around
<wpwrak>
i think the current design allows you to use things like function names as variables. i wonder if a) this works and b) if anyone actually uses it ? if not, they could all be sorted out in the scanner. poof, current O(n) searches become O(1) and the whole symbol table shrinks :)
<sb0>
by 500 bytes? doesn't really matter
<sb0>
are you sure those strcmps are slow?
<sb0>
I mean - of course they are, but is their effect really noticeable on the whole thing?
<wpwrak>
slower than, say, a pointer comparison. not sure how slow exactly, though
<sb0>
anyway, time to get to Grenoble
<sb0>
bye
<wpwrak>
have fun !! :)
<wpwrak>
hmm, is there a way to permanently save the network and performance settings such that they survive a reboot ?
<wpwrak>
ah, now it happened. seems to be semi-automatic :)
<n0carri3r>
morning all
<kristianpaul>
morning
<n0carri3r>
hi :)
<wolfspraul>
good morning!
<wolfspraul>
(though 10.30 pm here...)
<wpwrak>
wolfspraul: high time to get up :)
<wolfspraul>
Jon and I had a good meeting with a guy named Markus from metrowaves today (I think those were the names)
<wpwrak>
urban vibes ?
<wolfspraul>
new perspective. Markus talked about LED walls and their unusual aspect ratios (he played with one that had a 13:2 ratio)
<wolfspraul>
he was wondering how well the Milkymist could auto-detect audio sensitivity, and do so in different frequency bands in parallel
<wolfspraul>
he asked whether the DMX could sync the light color with the color on the display-out. say some effect on the display turns red -> the color info over DMX turns red
<wolfspraul>
is that possible?
<wolfspraul>
he felt audio latency is not so important, in fact if it's perfectly synced people don't like it, they need some space
<wpwrak>
i guess the auto-level needs experimenting. the EWA would be easy enough, but then you probably need some fine-tuning
<n0carri3r>
wolfspraul == wolfgang?
<wolfspraul>
yes
<n0carri3r>
ah, it's don! hello :)
<wolfspraul>
that was about it
<wolfspraul>
yes already knew it
<wolfspraul>
n0carri3r
<wolfspraul>
:-)
<n0carri3r>
haha yes
<wolfspraul>
it looks like we can work with a club in Beijing to be our guinea pig
<wolfspraul>
Lantern
<wolfspraul>
they will buy one, and then we will finetune based on their feedback over some months
<n0carri3r>
i was here last night for a bit, working on importing milkdrop presets via FTP - got a lot of them working with no modifications
<n0carri3r>
i will be posting more information on the wiki soon
<wolfspraul>
'finetune' meaning we will hopefully be able to relatively quickly implement things that make the box more valuable for Lantern
<n0carri3r>
i don't have the MM here at the moment, but i do have two questions: 1. is there a list of variables and functions somewhere that is complete? 2. is there a limit to the number of per_frame variables that can be used?
<wolfspraul>
as with some of Markus questions above, my answer is: don't know
<wolfspraul>
:-)
<n0carri3r>
both of these are related to porting milkdrop presets smoothly to FNP
<wolfspraul>
I'm still expanding my knowledge of all this
<n0carri3r>
OK, should i try the mailing list?
<wolfspraul>
no, here is perfect
<wpwrak>
(auto-level) what may also help is to adjust the patches to have more uniform expectations on the levels. at least they seem to be all over the place, with one already going mad when a feather drops while the next hardly moves when your ear drums swap places
<wolfspraul>
probably right now the only person who can give you fast and definitive answers on such details is Sebastien, nicknames lekernel or sb0
<wolfspraul>
he is traveling a bit right now, demoing m1 here and there
<wolfspraul>
sure you can send to the list too, it will neither be faster nor slower than here
<wolfspraul>
wpwrak: agreed
<wolfspraul>
do you know whether we can react with different effects on different frequency bands?
<wpwrak>
n0carri3r: the value relevant at the moment would be in the "Original" group, column "Regs"
<n0carri3r>
thanks - that is interesting, as i was getting some errors that seemed to be related to lack of registers, when importating milkdrop patches
<wpwrak>
n0carri3r: in the future, FN will use an often more efficient algorithm, in the "New (LCFP)" group, again "Regs"
<wpwrak>
hmm yes, some of the shipped patches already pretty much max it out
<kristianpaul>
ac97 core dint implemented fft but other method (FIR?), now is still have registers that cab read for something useful..
<wpwrak>
luckily, it's particularly the pathological cases where the new algorithm will help most :)
<wpwrak>
wolfspraul: (frequency bands) afaik, yes. at least there are frequency-related variables. i only glanced at the semantics so far, though
<kristianpaul>
wpwrak: oh nice, wich variables?
<wpwrak>
should be bass, mid, treb, bass_att, mid_att, treb_att,
<wpwrak>
maybe there's more
<kristianpaul>
okay and what frequency-range correspond to each one?
<wpwrak>
"low, medium, and high" ;-)
<wpwrak>
that's all i know :)
<kristianpaul>
hum ..
<n0carri3r>
and the att variables, like bass_att
<n0carri3r>
should be attenuated, or a bit smoothed out i think
<wpwrak>
kristianpaul: maybe check the thesis if there's anything. or else the implementation :)
<n0carri3r>
so they may not react as violently to sudden changes in volume on a specifc frequency range
<n0carri3r>
i'm guessing, just based on the variable name and what it stands for :)
<kristianpaul>
yeah, i was worryinng about it
<n0carri3r>
but of course it's good to EQ the sound, maybe even between the main board and the milkymist, for your purposes :)
<kristianpaul>
to wide, PD people may laught on me if said that :)
<wpwrak>
(dampening) an EWMA should be easy enough to calculate: avg = x*value+(1-x)*avg
<wpwrak>
not sure if variable life time is suitable for this, though