<kristianpaul>
i need that, i was crazy compiling all this from scratch some hrs ago
<kristianpaul>
i dont get why i need a MMU beyond the fact running linux is good, but yeah, talk on ML looks interesting
<kristianpaul>
aw_: you are genious !!!
<kristianpaul>
ALL this time i had a canon cemra with A/V out, and now i realized i can plug it on the MM1 :(
<kristianpaul>
as you can see on irc i always had the video out with my camera.. :(
<aw_>
kristianpaul, all i did was xiangfu taught me! :-)
<aw_>
kristianpaul, since i have to recognize how MM1's goes before/after i add parts on video circuit path. so I asked xiangfu that how i can capture video snap on gui. :-)
<xiangfu>
we should add the 'multi patch performance' to this page :)
<wolfspraul>
xiangfu: I had another idea :-) after booting, m1 should automatically start with a patch, or even randomly picking one and then randomly continuing with others
<wolfspraul>
or if it's possible, after booting it should continue with whatever it did before the last power off
<xiangfu>
I was thinking auto select one. not auto start :) then when you click "start!" no needs to select.
<wolfspraul>
xiangfu: I think the best would be if m1 continued with whatever it was doing before the last power-off
<wolfspraul>
maybe with some way to escape from the loop, so people cannot get stuck in a crash
<kristianpaul>
xiangfu:Â Â i did
<kristianpaul>
eraseflash 0xD20000 151
<kristianpaul>
flashmem  0xD20000 data.flash5.bin noverify
<kristianpaul>
but got /flash empty
<wolfspraul>
but other than that I think that would be good. if it was in the GUI - back to gui. if it was running some patch X, back to patch X. if it was running multiple patches, back to the same set. etc.
<xiangfu>
kristianpaul: how you create the data.flash5.bin . there is one parameter "convert" like
<wolfspraul>
xiangfu: ahh! :-) so the video-in-switch-resolution is the newer one?
<xiangfu>
wolfspraul: yes. but a bug :)
<xiangfu>
switch 32 times :(
<wolfspraul>
does video-in-switch-resolution replace the older one?
<wolfspraul>
if so, just delete the older one
<wolfspraul>
even if someone runs into it (unlikely), it is better to delete known bad stuff than to let people fall into a trap
<wolfspraul>
these are just temporary/personal builds anyway...
<xiangfu>
I add that one for back the source code patch.
<xiangfu>
wolfspraul: when I move the big video-in preview. I can feel that is slow then the small one.
<wolfspraul>
ok sure. I don't feel very strongly that a larger preview-in needs to be the default, I just need it for some camera comparison screenshots.
<wolfspraul>
not worth further discussions...
<wolfspraul>
(for me at least :-))
<wolfspraul>
I'm curious what Sebastien thinks about the m1 after booting going back to what it did before last power off.
<wolfspraul>
I think that would be a cool feature with real end user value.
<wolfspraul>
we find out later :-)
<xiangfu>
yes.
<xiangfu>
for now. too bad. after reboot. all keyboard bindings are lose :(
<wolfspraul>
it should remember 'the whole' state over power cycle
<xiangfu>
'DMX desk' setting lose too.
<wolfspraul>
I think we first define the goal. I think it should remember the full state and go back to do exactly what it did before.
<wolfspraul>
if Sebastien agrees, then we can start with the most important settings/states first, and then the more advanced ones
<kristianpaul>
btw i noticed i have to reboot with the video camera connected in order to the patches to work well
<kristianpaul>
this is when changing resolution
<wolfspraul>
yes I also noticed some strangeness in the video-in signal not being detected unless I reboot
<wolfspraul>
but I didn't have the time yet to track it down into a proper reproducible procedure...
<wolfspraul>
or maybe what I saw was that plugging the camera in hung the entire m1, when I was in the preview dialog already I think. I need to make it properly reproducible first. All small bugs I think.
<lekernel>
for large video in preview just use a patch
<lekernel>
video_a=1
<lekernel>
decay=0
<lekernel>
this will put the video in fullscreen with no effect
<lekernel>
and with hardware acceleration so this will get a good framerate - not like the preview dialog
<aw_>
good, but modify video_a=1, decay=0 to which file?
<aw_>
to test our video-in circuit. man! i need to think about this.
<xiangfu>
aw_: how about same that picture to your camera :)
<aw_>
xiangfu, yup..just need to 'feed' SMPTE color bar into our connector J18's 'green' one. i.e. we needs a camera source it can generates a standard color bar pattern.
<aw_>
i can download color bar sources from web somewhere. but this likes you surveys a VGA >> S-video & composite video RCA out, then connects it into our M1. :-)
<aw_>
well...this conversion kit won't be a pure color bar source.
<xiangfu>
Output written on handbook.pdf (31 pages, 165293 bytes).
<wolfspraul>
lekernel: I was curious what you think about my idea that after power cycling, the m1 should go back doing whatever it did last, remembering all state info if possible
<wolfspraul>
if you agree with that general goal, xiangfu can slowly implement missing features in that direction
<lekernel>
there's already a performance autostart mode
<wolfspraul>
how is it invoked?
<xiangfu>
lekernel: there is a autostart in system settings don't know how to use that.
<lekernel>
should be enough for most real life purposes imo... or do you have something specific in mind?
<lekernel>
just select a .per multi-patch-performance file
<lekernel>
and it will start at boot (before displaying anything on the screen so it can be used in live contexts)
<wolfspraul>
ok I will try that.
<wolfspraul>
I was more thinking as a general idea - m1 goes back to what it did last after power cycles.
<lekernel>
that's a lot more complex to do with little benefits imo
<xiangfu>
lekernel: what is the .per file format?
<lekernel>
what feature would that enable?
<wolfspraul>
I'm not asking you to do it, I am just curious how you feel about it from a product design perspective.
<lekernel>
well, no matter who does it, this requires adding hooks all over the code and making it a bit messy
<wolfspraul>
you probably think too radical.
<wolfspraul>
I am just curious about how you think the user would like that behavior.
<wolfspraul>
or not like it
<wolfspraul>
always going to the same starting point also may be desirable
<wolfspraul>
people may get stuck in something they don't want
<wolfspraul>
where others may feel the product is much more robust/easy to use, if it always goes back to what it did last
<lekernel>
yeah, or in case of a bug, to an unrecoverable state
<wolfspraul>
yes but I am asking about what is desirable
<wolfspraul>
not for you to think through technical details
<lekernel>
xiangfu: when you make a multi patch perf, click "save" on the control panel and it makes such a .per file
<wolfspraul>
I will play with the existing gui a bit more first, there are more features I don't know well yet.
<wolfspraul>
like 'performance autostart mode'
<wolfspraul>
as a product design goal, I somehow like "go back to what it did last"
<lekernel>
well, don't reboot it then :)
<lekernel>
i'd prefer the product to be rock stable so it never has to be rebooted rather than messy "session save" code so the bugs are bearable
<wolfspraul>
that's why I think it's a valuable feature, because I think in real life settings, there will be a lot of unplugging, moving the box, changing power strips, etc.
<wolfspraul>
ah I did in no way suggest to do this to cover up crashes
<wolfspraul>
I am talking about product design goals
<wolfspraul>
in fact as you pointed out (getting into an unrecoverable state), this 'go back' thing would require a rock solid foundation to be fun to use
<wolfspraul>
but I am not asking you about technicalities, I'm asking about what is desirable for our users
<wolfspraul>
of course over time we will hear, if we ask and listen carefully
<wolfspraul>
but we can also have some thoughts in advance :-)
<lekernel>
imo the next thing that should go away in the GUI is the control panel
<lekernel>
it looks ugly, makes people afraid and isn't intuitive
<lekernel>
I'm thinking about replacing that with good looking icons describing the complete system (with lights, screen, dmx desk, camera ...) which pop up the appropriate window when you click on them
<lekernel>
I think this is much more important than a small detail like the session system
<kristianpaul>
well, not so blur, may be tricky zoom :-)
<methril_work>
lekernel, any news/work with gcc 4.6?
<methril_work>
who is a gcc master?
<lekernel>
i'm not
<lekernel>
and tbh, don't really want to be one
<methril_work>
i would like to debug
<methril_work>
and get them compiled
<methril_work>
i don`t want to, but i would like to see gcc with full support :)
<lekernel>
otoh, if you send me a patch I can commit it to the GCC repository in less than 24 hours, which is already a progress compared to the previous LM32 situation
<methril_work>
nice picture, this acrylic looks better
<methril_work>
ok
<methril_work>
i see some rtems people dealing with all the newlib,gcc, binutils....
<methril_work>
do you think they could help?
<lekernel>
you can try asking around, but keep your hopes low
<lekernel>
if I were you i'd rather help with the LLVM port
<kristianpaul>
likes pcc
<methril_work>
i don't know anything about LLVM (neither GCC)
<methril_work>
but i have to deal with GCC
<methril_work>
we need GCC for Linux
<lekernel>
ok, then LLVM is clearly advantageous for you since it has documented internals
<lekernel>
GCC does not by FSF policy :=]
<kristianpaul>
oh really? what about comunity support?
<lekernel>
they get trolled by FSF people... hahaha
<kristianpaul>
:p
<kristianpaul>
lekernel: whats the max trougput you achived with the uart core?
<kristianpaul>
what was*
<lekernel>
about 230k
<lekernel>
this uart design isn't meant to be fast
<lekernel>
maybe you can use ethernet instead
<kristianpaul>
hmm i dint tested the last minimac2 revision yet
<kristianpaul>
but seems i should do some ttcp tests..
<methril_work>
well, lekernel thak you
<lekernel>
haven't had any ethernet bug other than the PHY reset problem since I introduced minimac2
<methril_work>
i'll do some more tests
<kristianpaul>
nice :-)
<methril_work>
and if i get tired of not finding anything, i'll try LLVM
<kristianpaul>
brave guy :-)
<methril_work>
:)
<larsc>
mwalle: why do we want deprecated syscalls?
<larsc>
or is this just for the moment so uClibc works?
<mwalle>
larsc: mh? which ones?
<mwalle>
you mean the defines?
<larsc>
yes
<larsc>
#define __ARCH_WANT_SYSCALL_DEPRECATED
<mwalle>
iirc uclibc needs one of those
<larsc>
ok
<larsc>
the old syscall deprecated syscall be implemented by the means of of newer ones, but i guess uClibc has support for it yet. i'll take a look
<mwalle>
larsc: if it can be removed, i'll happy with that ;)