<qwebirc19070>
And I'd like to add Milkymist to the show... we are about to release a new album.
<qwebirc19070>
... and when rejon introduced the MM, I thought it was perfect for my performances... since I could interact with the musicians
<qwebirc19070>
Using the camera...
<wolfspraul>
qwebirc19070: definitely just order in the online shop, absolutely no problem about Argentina
<qwebirc19070>
GREAT!!!
<wolfspraul>
the one issue though maybe the power supply, though I'm not sure how bad that really is
<kristianpaul>
:D
<qwebirc19070>
I'm eager to test it!
<wolfspraul>
what I can offer you is this: we ship the m1 to you without the power supplies, and ship the power supplies separately in a cheaper way (non-fedex). maybe just a small parcel or letter or so.
<wolfspraul>
they will arrive much later though if we do it this way
<wolfspraul>
or we leave them out entirely, we use very standard 5V and 12V DC jacks
<wolfspraul>
(5V for the M1, 12V for the camera)
<qwebirc19070>
But a 5V power source is VERY common... I can use one of the tens I have in a box...
<wolfspraul>
yes
<qwebirc19070>
yeah!
<qwebirc19070>
:-)
<wolfspraul>
ok then we leave them out
<wolfspraul>
thank you
<qwebirc19070>
great!
<qwebirc19070>
Anything else you recommend including in the shipping?
<wolfspraul>
the only other thing I sell is the Ben NanoNote, that device only makes sense for big time free software connaisseurs right now :-)
<wolfspraul>
say if you think that mutt is the best email client in the world
<wolfspraul>
then you may want to throw in the Ben NanoNote as well :-)
<qwebirc19070>
not mutt, I'd love elm
<qwebirc19070>
;-)
<qwebirc19070>
hahaha
<qwebirc19070>
elm over UUCP... POP3 is too modern for me
<qwebirc19070>
I used to configure sendmail.cf by hand...
<qwebirc19070>
... so I will probably include the Ben too!
<kristianpaul>
*g*
<wolfspraul>
even better, they are both serious products and we put our whole hearts into this stuff
<qwebirc19070>
I know, It's really evident and I really support the concept behind these products.
* kristianpaul
check wikipedia about uucp
<kristianpaul>
wow before tcp/ip !!!
<qwebirc19070>
I used to do administration on a Santa Cruz operation
<qwebirc19070>
(SCO)
<qwebirc19070>
I replaced it with one of the first Slackwares... great suffering having to compile EVERYTHING
<qwebirc19070>
Sometimes I can't believe that we have "apt-get install apache" now... hahahaha
<kristianpaul>
xD
rejon joined #milkymist
<qwebirc19070>
One more question, wolfspraul... does the Ben also use standard power supplies?
<kristianpaul>
It uses generic usb type b cable
<qwebirc19070>
wow, great
<kristianpaul>
mini usb**
<qwebirc19070>
I'm so happy, these two beauties will do my self-christmas present.
<qwebirc19070>
f** ! My card is not accepted...
<qwebirc19070>
I will try later, there has been some changes in Argentina regarding dollar buying...
<qwebirc19070>
Thanks a lot for your help! Bye!!!
<wolfspraul>
qwebirc19070: if you have card problems, you can also email me at wolfgang@sharism.cc to work it out
<kristianpaul>
band, nice all dmx, midi there !
<wolfspraul>
kristianpaul: what?
<wolfspraul>
(don't understand the context...)
<kristianpaul>
youtube video link above?
<kristianpaul>
19:56 < kristianpaul> Do you work with visual performances or related field?
<kristianpaul>
19:56 < qwebirc19070> I do some acting during my sister's show.
<kristianpaul>
wolfspraul: I just mention, considerin the posibillity qwebirc19070 may use its M1 with this devices in a future.
<qwebirc19070>
I'll definitely try it.
pablojavier joined #milkymist
<pablojavier>
Yeah, no more qwebirc19070 :-)
<pablojavier>
I will certainly try the M1 with MIDI controllers
<wolfspraul>
one step at a time. let's get one delivered to you first, then you start playing with it :-)
<wolfspraul>
where in Argentina are you?
<pablojavier>
buenos aires
<pablojavier>
I did the checkout for the M1 and the Ben
<pablojavier>
But my cards were rejected
<pablojavier>
I will call VISA tomorrow and try again
<pablojavier>
hope it arrives so I can put it under my tree!!
elldekaa joined #milkymist
errordeveloper joined #milkymist
lekernel_ joined #milkymist
rejon joined #milkymist
xiangfu joined #milkymist
azonenberg joined #milkymist
<GitHub161>
[scripts] xiangfu pushed 1 new commit to master: http://git.io/8RzElA
<GitHub161>
[scripts/master] update to latest Milkymist Makefile system - Xiangfu Liu
<lekernel_>
wpwrak: what do you mean, non ansi prototypes? foo() instead of foo(void)?
<lekernel_>
what's the problem with that? all today's compilers handle this and it's less typing
<lars_>
without the void you can pass as many parameters to a call of foo without generating a compiler error
<wpwrak>
lekernel_: yes, that's what i meant. and lars explained it :) also, the compiler may generate slightly less efficient code in such cases
<lekernel_>
mh? C is sick.
<lars_>
C is full of backwards compatibility
<wpwrak>
we could use -Wstrict-prototypes to bring out these critters
<wpwrak>
or, more directly: -Wold-style-declaration -Wold-style-definition
<wpwrak>
also -Wextra may be a good idea
<wpwrak>
the chars vs. isalnum bother me, though. not sure how to fix that. where does our newlib come from ? is this via rtems ?
<lekernel_>
via rtems
<lekernel_>
I think they'd patch it if we report the problem
<wpwrak>
let's see if i can find it ...
<wpwrak>
cpukit/pppd/chat.c ;_) but no, that's not the one
<wpwrak>
it's a pity that lemon doesn't support yacc-style 'x' syntax (for terminals). that makes parsers so much more readable
<wpwrak>
and it also helps with debugging the grammar, because you can quickly insert a unique terminal and see if this solves the conflict
<wpwrak>
hmm, one bug in my migration. i forgot to move the fpvm_assign prototype. well, i'll do that later
<wpwrak>
lekernel: hmm, what's the correct way to signal an error to the parser ?
<wpwrak>
(from inside the grammar)
<wpwrak>
hmm, perhaps you don't. there's no error indication interface to the caller anyway.
lekernel_ joined #milkymist
_whitelogger [_whitelogger!~whitelogg@2a00:ab00:1::4464:5550] has joined #milkymist
_whitelogger1 [_whitelogger1!~whitelogg@2a00:ab00:1::4464:5550] has joined #milkymist
<wpwrak>
lekernel_: Q: semicolons in a patch: how should the grammar handle them ? 1) optional, 2) required as separator, 3) required as terminator ?
<GitHub131>
[scripts] xiangfu force-pushed master from 8581de4 to 33f5b11: http://git.io/DOsw5Q
<GitHub131>
[scripts/master] update to latest Milkymist Makefile system - Xiangfu Liu
kristianpaul [kristianpaul!~kristianp@cl-498.udi-01.br.sixxs.net] has joined #milkymist
kristianpaul [kristianpaul!~kristianp@unaffiliated/kristianpaul] has joined #milkymist
kilae [kilae!~chatzilla@catv-161-018.tbwil.ch] has joined #milkymist
elldekaa [elldekaa!~hyviquel@lns-bzn-44-82-249-208-134.adsl.proxad.net] has joined #milkymist
kilae [kilae!~chatzilla@catv-161-018.tbwil.ch] has joined #milkymist
DJTachyon [DJTachyon!~Tachyon@ool-43529b4a.dyn.optonline.net] has joined #milkymist
<lekernel_>
wpwrak: they're optional, used to separate several equations on the same line
<wpwrak>
the grammar seems to be fine if i make them entirely optional
<wpwrak>
of course, you cuold then do things like foo=1 bar=2 ....
<wpwrak>
not sure if this is good or bad
<wpwrak>
requiring ; for multiple equations in the same line would of course make things complicated when assignments are split over multiple lines
<wpwrak>
btw, why is [ a comment character ? looks like an odd choice. is this really used for comments or for something else ?
<lekernel>
no, that's because the original milkdrop presets are based on INF files
<lekernel>
they have a "[preset]" at the beginning that should be ignored
<wpwrak>
aaah ;-)
<wpwrak>
well, we shall have sections in the future, too. but i think something like per_frame: will look nicer than [per_frame]. particularly since we may have some use for [...] elsewhere
<wpwrak>
(in the future)
<wpwrak>
what do you think of adding proper relational operators, a == b, a > b, etc. ?
<wpwrak>
and maybe a form of the ternary operator instead of LISP-ish if(a,b,c). as much as i like LISP as a programming model, i find the syntax painful
<lekernel>
yeah, why not :)
<lekernel>
the first goal was to support MD :)
<lekernel>
but ofc it can/should be extended
<wpwrak>
very good :)
<wpwrak>
for images, i'm thinking of having an array and an index variable. the array could have lazy evaluation, so you only preload a few at the beginning, and convert the rest in the background as the patch is running. not sure how this will pan out with CPU load, though.
<lekernel>
probably quite difficult to do without "hiccups", no?
<lekernel>
what if the image is suddenly needed?
<wpwrak>
you'd get some fallback behaviour. could be to ignore the change request or to show the highest available. it could also update when the image becomes available and/or when more images become available
<wpwrak>
there could also be a variable that tells you how far you can go
<lekernel>
sounds complicated to use
<wpwrak>
of course, if you need random access, then you'd just preload all of them
<lekernel>
nah... sounds difficult to use AND difficult to program
<wpwrak>
;-)))
<lekernel>
pick your battles :)
<wpwrak>
there may be other options. like caching converted images. or introducing a "raw" format where the image is pre-converted by the user
<wpwrak>
need to see what works
<lekernel>
is it really so slow that you need such things?
<wpwrak>
in any case, i want image arrays. not for silly slide shows but for having patches with fancy effects
<wpwrak>
haven't measured conversion times yet
<wpwrak>
but i can imagine that a large image collection could take some time
<wpwrak>
but we'll see. that's not something i'll get to today or tomorrow. first, parsing the whole patch in one run. fpvm_assign must die :-)
elldekaa [elldekaa!~hyviquel@lns-bzn-44-82-249-208-134.adsl.proxad.net] has joined #milkymist
<wpwrak>
hmm. the parser is indeed remarkably good at not reporting problems ... and actually somehow getting past them. yet another area that wants attention.
n0carri3r [n0carri3r!~nocarrier@184.152.67.214] has joined #milkymist