Personal tools
You are here: Home community IRC Chat Logs dev@irc 05/1
Document Actions

dev@irc 05/1

by IOhannes m zmoelnig last modified 2005-03-19 05:50 PM

logfile of the 1st dev-meeting @ IRC on 26/02/2005 as found on http://artengine.ca/matju/dataflow-20050226-meeting.irc

[2005.02.26, UTC 16:58-21:09]

<matju> xovo: well i don't recall exactly, but i must have drank beer at least 8 days in a row, no?
<IOhannes> matju: miller+UTC, thats "??"; but i think you explained it already
<IOhannes> good start: drinking, wekk, enuff
<matju> IOhannes: he said he'd be there at 10:00 PST, "which is 17:00 UTC" (sic)
<xovo> can't really remember, there was too much beer on my side as well
<xovo> hey, the ole days
<Qbert-Afk> ey xovo: was that new flext build system you talked bout released yet?
<tigital> matju: that'd be another hour...maybe I'll go eat lunch
<matju> like, i came in 135 minutes too late, and miller said i should have been there because there were questions for me but that it was now too late because the meeting was already finished
<IOhannes> should i answer pd-dev-mails or not ?
<IOhannes> i mean right now ?
<Qbert-Afk> why not?
<matju> IOhannes: i often handle mails at the same time as IRC
<Qbert-Afk> anybody turned on logging?
<matju> IOhannes: if you're in MS-DOS, then you should launch DESQview so that you can use the mail program at the same time as the chat program
<xovo> Qbert: i'm still working on a few details with flext 0.5.0... the build system will be released with that one
<matju> Qbert-Afk: i will save the buffer after it's done.
<Qbert-Afk> xovo: ok cool
<IOhannes> matju: i'll try and find my boot-disks
<Qbert-Afk> matju: ive started logging, so if your mac happens to crash ;-)
<Qbert-Afk> i know how unreliable those can be
<IOhannes> ah, ybout logging: should we publish the logs after the meeting
<xovo> qbert: but you can try it out already with the cvs version (which is pretty stable)
<IOhannes> (i am positive about this)
<Qbert-Afk> i would say that is a good thing to do
<IOhannes> i mean, the IRC-logs
<Qbert-Afk> perhaps even post it to pd-dev
<matju> Qbert-Afk: i'm running a k7-2166. the mac is only my laptop and i don't use it except when travelling
<tim_blech> posting it to pd-dev os a good idea ... but if someone doesn't like it, please say NO ...
<Qbert-Afk> matju: wow, i thought you were a machead
--- Qbert-Afk is now known as Q-LogOn
--> wip (~wip@Kitchener-HSE-ppp3572680.sympatico.ca) has joined #dataflow
<matju> Qbert-Afk: if it were the case, GridFlow would not suck on the G3/G4/G5.
<IOhannes> tim_blech: i'd prefer having it online (but we'll see how long it gets)
<IOhannes> tim_blech: couldn't you change your nick to just "tim"
--- tim_blech is now known as tim
<tim> IOhannes: works ... the problem is, i'm not the only one having this nick on this server ;-)
<Q-LogOn> matju: was a win32 version of GF released?
<matju> Q-LogOn: ask "ja"
<IOhannes> tim: thanks
<matju> Q-LogOn: ja = ix = carmen
<Q-LogOn> ja == xi?
<Q-LogOn> ja
<Q-LogOn> :), ja == yes in dutch
--- xovo is now known as grrrr
<matju> hi mr grrrrill
<IOhannes> shadows falling from my eyes
<grrrr> hi Mr. Matsjeu
<matju> Matsjö with the iso-latin-1
<grrrr> there another grrrr on freenode, that's why
<tigital> what about grrr?
<matju> btw the default around here is iso-latin-1 and not unicode.
<grrrr> my name is grill, not gril
<tigital> hehe
<grrrr> ööö
<tim> grrrr: ever went to www.grrr.org?
<grrrr> no, but http://www.grrrr.net is quite nice
--> geiger (~geiger@mtg68.upf.es) has joined #dataflow
<matju> geiger: hi
<geiger> hola
<IOhannes> hi g?nter
<geiger> hallo Johannes
<geiger> bin a bisserl spät
<matju> IOhannes: your client is in 7-bit mode (sorry)
<IOhannes> na ja, miller isn't here yet, so is wini
<IOhannes> matju: i didn't care, but i love typing umlauts when they are not available
<IOhannes> (so i do care)
<IOhannes> i am curious whether thomas m. is going to jioin
<IOhannes> but in the meantime i will ask how this is supposed to be;
--- geiger is now known as gige
<IOhannes> all talking on the one single channel ?
<tim> possibly ... i hope that miller can give a brief intro about his future development (39) and then ... matju and i added some topics to the wiki....
<grrrr> is there a need to fork?
<tim> http://puredata.org/Members/timblech/TopicsForTheDeveloperMeetingsOnIrc
<IOhannes> grrrr: i don't know, i am just asking how such things are handled on other meetings
<grrrr> i never had one ;-)
<IOhannes> tim: i have put a news-ticker onto the puredata.org to announce both the meeting and your site
<gige> we always meet in one room
<IOhannes> ok
<gige> ah I see, tims list has grown
<tim> btw ... who is "higgs"?
<tigital> drat...gotta run, but should be back in an hour
<-- tigital has quit ()
<matju> tim: the only higgs i know is the famous boson
<IOhannes> where is higgs
<tim> he offered to have a look at the alsa midi implementation, but i'm not familiar with him ..
--> alx1 (~alx@HSE-Kitchener-ppp232081.sympatico.ca) has joined #dataflow
<IOhannes> ah, i just wanted to talk about that (before miller comes)
<IOhannes> hey alex
<alx1> hello
<gige> ah, i thought this was a higgs because of too much alcohol
<IOhannes> what is wrong with the alsa-midi thing in devel (or wherever) ?
<IOhannes> i thought it was running fine (but i admint i never tried it)
<gige> there is a patch, it works, but needs some cleanup
--- ChanServ gives channel operator status to matju
<tim> no idea ... i'm not using midi ...
<IOhannes> gige: cleanup for readability or because it f***s up things ?
--- matju has changed the topic to: The Diagram Is The Program (tm) | PUREDATA DEVEL MEETING TODAY at about 18.00 UTC (waiting for miller)
<gige> ah, there is just some leftover formcopy/paste
<gige> nothing dangerous
<gige> the ALSA midi API is really good (as oposed to the audio API)
<IOhannes> good, but then there is no problem to integrate it (i mean, it might be 2 hours work (at a maximum))
<gige> yes
<gige> i mean, no no problem
<IOhannes> i understood it that way (but didn't knoiw what to answer ;-))
<tim> ... while waiting for miller, we can start to discus some of the other topics ...
<gige> I see, though you werre waiting for an explanation, anyhow, I think the diff on the tracker has
<gige> a small problem.
<IOhannes> i'll try...
* IOhannes is going to patch amidi
<tim> matju suggested to distribute devel_0_38 binaries ... is there any possibility of providing daily builds for every plattform via sourceforge?
<grrrr> not for WIndows, i think
<IOhannes> isn't there a cygwin/... environment ?
<tim> for windoze there is also the problem, which compiler to use ... iirc you'll have to use the same compiler for both pd and all externals ...
<IOhannes> probably crosscompiling ?
<hans_> for GNU/Linux and MacOS X it should be possible
<hans_> I think you could cross-compile on GNU/Linux to cygwin
<grrrr> cygwin is a pain, i have had some troubles with it
<hans_> but that might mean using Cygwin's Tcl/Tk then, meaning X
<IOhannes> which might be a problem
<IOhannes> but there is none with the constraint of pd and externals needing the "same" compiler
<hans_> There is a Debian and a Fedora x86 box in the sourceforge compile farm
<hans_> http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1#cf_overview
<hans_> I have a Windows box that I barely use, so we could set that up as a daily compile box
<gige> what about mingw
<grrrr> mingw runs under Windows...
<matju> carmen (ja) prefers mingw
<hans_> I don't think you could compile to mingw on linux since mingw uses the Windows libs, but I could be wrong
<hans_> if all the libs were DLLs, perhaps
<hans_> mingw is definitely the way to go for Pd, I think
<grrrr> the performance is not comparable to VC, though
<hans_> you tested it?
<grrrr> yes, there's a big difference
<gige> http://members.telering.at/jessich/mingw/mingwcross/mingw_cross.html
<hans_> as far as autobuilding, I think the first to do would be get Debian going
<hans_> that'll be the easiest by far
<IOhannes> gige: this doesn't look to promising (apart from the proof of concept)
<IOhannes> *too
<hans_> yup
<gige> :) I know, wrong page
<gige> but it exists
<gige> anyhow, effectively it would be better to compile with VC
<IOhannes> true
<grrrr> i think there's also a free version, no?
<gige> yes, perfect for pds makefile
<hans_> right, but I hear that does zero optimization
<tim> there is a "free" beta version of vc ...
<grrrr> yes, but this one is usage-limited
<hans_> I don't think free MS VC is a workable option
<tim> well, more or less ... i used it to compile the win32 binaries, for the asio code ... wasn't limited for me ...
<hans_> if we want free, I think we need to go with MinGW
<hans_> unless things have changed recently
<grrrr> I'll see if i can find the performance numbers...
<tim> the msvc command line compiles _is_ free
<hans_> right, but can you confirm that it includes the optimizer?
<hans_> last time I looked into it, the free CL VC compiler did not do any optimization
<hans_> optimizing MinGW has got to be better than non-optimizing VC
<-- alx1 has quit ("Leaving")
<tim> it's said to be the same compiler as in visual c++ standard ...
<grrrr> http://msdn.microsoft.com/visualc/vctoolkit2003/
<IOhannes> and does the cl-vc support simd ?
<grrrr> seems like it's free AND optimizing
<tim> cl should support handcoded assembler ...
<grrrr> Iohannes: yes, there is a command-line flag - but it's not really vectorizing
<tim> well, i doubt that ANY compiler can create simd-optimized code from pd's sources...
<IOhannes> ah, that is because i always use intrinsics when doing SIMD (don't like asm)
<matju> tim: what, you aren't even running GCC 5.4.9 yet?
--> alx1 (~alx@HSE-Kitchener-ppp232081.sympatico.ca) has joined #dataflow
<tim> 1. the compiler doesn't know, if the memory locations are aligned ...
<grrrr> IOhannes...don't use them with MSVC...have a look at the code and you will use asm
<IOhannes> well, i use them with gcc, and they just work with msvc too...
<grrrr> tim: there's an __aligned keyword for most compilers
<matju> btw, what is proper alignment on OSX ? because i fear GF does it wrong, in a way that is perfectly ok on PC's
<tim> 2. the compiler doesn't know, if the block-size is a multiple of 4 / 8 / 16 ...
<IOhannes> tim: you neither ;-)
<tim> IOhannes: no, but i can write a runtime dispatching ;-)
<tim> the compiler might be able to do that, too, but it most likely doesn't know, where to do that ...
<grrrr> matju: i think it's the same alignment
<matju> tim: GF has some function-templates to handle such cases. For example, [#inner] runs different functions for when an image has 1, 2, 3, 4, >=5 channels
<tim> well, so you _wrote_ a runtime dispatching ...
<matju> yeah... several of them, whereever necessary... [#scale_by] and/or [#downscale_by] also
<matju> GF was originally written with variable number of channels anywhere, which is part of why it's slow
<IOhannes> btw, alsa-midi segfaults if you don't have a alsa-sequencer support (e.g. no proper module loaded)
<matju> some places have those specialisations, but they are not uniformly spread around C++ code, i only put them as i needed them
<gige> that *is* the smallproblem,its fixed in the debianpackage
<tim> see ... the compiler is usually a very stupid thing ... the only instance i saw that a compiler produced simd code was something like: for(int i = 0; i != 64;++i){/* do something very linear on the stack */}
<gige> obviously I did something wrong when reuploading the patch
<gige> ah, yes, and by chance ubuntu just did their debian snapshot when the broken packages was in :(
--> chokon (asds@109.red-62-57-183.user.auna.net) has joined #dataflow
--> krzYszcz (krzYszcz@dqk79.neoplus.adsl.tpnet.pl) has joined #dataflow
<IOhannes> gige: yes your patch seems not to be on the sf-site
<gige> this is why I get angry when people don't report bugs, but the take away my time because
<gige> the don't know how to compile.
<matju> krzYszcz: welcome!
<IOhannes> well, i haven't need the amidi yet, so ...
<IOhannes> krzYszcz welcome too (long live copy'n'paste)
<matju> IOhannes: which one you pasted, "welcome", or "krzYszcz" ?
<IOhannes> actually i tried to just copy "krzYszcz", but "welcome" came too ...
<tim> emacs is so easy ;-)
<tim> to get back to the topic ... there has been some discussion about the symbol hash table of pd ...
<IOhannes> to enlargen it ?
<IOhannes> or to completely remake it ?
<IOhannes> or to add another one ?
<gige> to garbage collect it ?
<matju> i suggested multi-level symbol tables
<tim> currently it's a 11 bit hash table, which is definitely too small ... i once figured out, that a plain pd with externals takes several thousand symbols ...
<matju> there would be one symbol-table per abstraction instance or loaded patch
<tim> my performance patch had about 20000 symbols ...
<IOhannes> tim: are you trying to moocow ?
<matju> tim: would the multi-level symbol table reduce your symbol-count ?
<tim> IOhannes: no ... it was my audio performance patch ...
<grrrr> matju: how would you implement them? connect to $0-symbols?
<tim> matju: no, but it would help to distribute it ...
<IOhannes> matju: but how could the ml-table reduce the symbol count ?
<IOhannes> matju: oh i see, sorry
<matju> IOhannes: smalltalk-style: two kinds of symbol-tables: one for just handling gensym() and numbering the symbols; one for holding variables; then all the $0-foo would share the same symbol foo but have different var content
<grrrr> sounds good
<matju> then also the var-tables (let's call them this way now...) would get deleted as the abstraction or patch is deleted from RAM
--> msp (~msp@musicsf2.ucsd.edu) has joined #dataflow
<matju> msp: welcome.
<matju> msp: you are late.
<msp> hi there... (you found me fast...)
<grrrr> only 9 minutes probably
<IOhannes> hi miller
<msp> hi there. Forgive my lack of IRC know-how...
<hans_> you're not the only one...
<matju> msp: PST is eight hours behind UTC, not six
<IOhannes> well i guess, only matju and alexandre (and gige) know how to use irc
<gige> i do not, actually
<matju> msp: we're not asking you to use irc colour codes and ascii-art, you know.
<grrrr> i'll learn it, i promise
<matju> msp: and UTC isn't part of the IRC spec ;-)
<alx1> IOhannes: you mean just let it sit while I do other things ;-)
<msp> right, I need to figure out how to make smiley faces next....
<IOhannes> grrr: colour codes
<IOhannes> should be:
<IOhannes> grrrr: promise learning colour codes ?
<grrrr> what's wrong with it?
<IOhannes> nothing, i jsut wanted to be sure...
<hans_> got to step out for about 10 minutes, I'll catch up then
<grrrr> i'm sure IRC only covers color, not colour
<IOhannes> most probably not in france or canada
<msp> anyhow, hmmm, let's see what needs talking about...
<IOhannes> (thanks)
<matju> msp: i never learned everything about irc... some people use it even more completely, with triggered scripts and moderator hierarchies and whatnot.
<msp> for example, eek, the current state of "main" "stable" "devel" etc branches?
<IOhannes> msp: people wanted you to "say what is planned for the next release and millenium)
<msp> yes, I hope, a release sometime next milleniumm... anyway,
<msp> I'm right now working on making better drawing and editing for "data".
<matju> msp: #dataflow is a small channel; #gentoo is, uh, 1000 (thousand) people in the same channel
<msp> It's in a bad state so I've been afraind to upload it.
<IOhannes> it has been in a bad state for quite some time...
<grrrr> this includes a new way of handling arrays right?
<msp> yes, I've got arrays unified between 'data' and 'tables'.
<msp> Still problems and questions though.
<msp> Here's a question... I think it's time to rename 'cos~" to avoid repeating
<msp> the confusion between period-1 and operiod-2pi
<msp> So I'm thinking "costab~" which states the case better.
<msp> But of course "cos~" would have to stay for teh next century
<msp> for compatibility....
<IOhannes> right
<matju> grrrr: IRC was first invented in Finland, and I'm pretty sure the colour codes are a defacto extension by an Arab guy, and now who cares about petty variations of speling ?
<tim> msp: about the arrays: have you been thinking of a way to implement thread locks for arrays?
<tim> to be able to do non-realtime operations (soundfiler, vasp)
<msp> Haven't thought closely about it, but I think more stuff is going into the "t_array"
<msp> structure, which is common between data and table arrays.
<msp> So any locking should probably happen there. But I wonder why just
<msp> arrays and not lists (like the list of stuff in a canvas).
<matju> msp: and costab~ would be which one ?
<msp> So perhaps the lock has to be more generally designed.
<IOhannes> matju: i think [costab~] is exactly like [cos~]
<msp> costab~ would be 0-1 (the most convenient.)
<IOhannes> only people will not be that confused about the functionality
<msp> But people wouldn't get as easily confised between "cos" and "costab~".
<msp> Oh yes, also "costab~" might also serve to remind folks that it's only good to 19 bits.
<IOhannes> so call it [costab19~] then...
<matju> tim: what i don't get about the locks is that why would you want to block the main thread ever? i'd rather use a "reservation" instead of a "lock", and get a notification when the array is not reserved anymore.
<grrrr> what also concerned me about arrays in the past is the way that they are drawn. If i remember correctly an object that modifies the content call a pd functions, which than redraws the array. But there's no way for other object to find out (like other GUI systems)
<grrrr> that's why i put the "update time" feature into devel
<msp> well, "cos~" gets used so often... needs a simple name.
<IOhannes> that's why i tried to avoid [costab_19bit~] anyhow....
<matju> msp: how much faster is it than calling cos() ?
<msp> how about sco~,... no, just kidding.
<msp> way way faster. Haven't measured it though.
<matju> msp: how much RAM is the table taking?... sounds like 512k ?
<msp> yep. 512x4 bytes.
<msp> Oh, I mean, nope. 512x2.
<matju> 2 megs then
<matju> uh?
<matju> ok, it's 19 bits in, 16 bits out ?
<msp> I mean, (oops again, 512 floats, 2Kbytes.
<msp> It interpolates linearly, uses all 24 bits of input (floating point mantissa)
<msp> but the table lookup error is about 19 bits down.
<matju> oh ok, it's a *small* table. i thought it was the large one
<matju> really?
<msp> It's a wierd situation. You don't want to do 4-point interpolation (too much computation)
<msp> but if you don't use any you have to have a huge table and then you
<msp> run slow.
<matju> msp: tried 3-point interpolation?
<gige> well, with current cache sizes it might be a question of trying
<tim> well, iirc the sse3 specifications will include hardware implementations of cos ... only one platform, though ... but better than nothing ...
<grrrr> by the way: it should b possible to use SIMD for such kind of table lookup...
<gige> I use 4096 without lookup for PDa
<gige> SIMD is not cross platform
<gige> ah, sorry,
--> bbogart (~bbogart@215.dialup.ccs.ryerson.ca) has joined #dataflow
<gige> confused with SSE
<grrrr> SIMD is not on PDa, sorry
<IOhannes> hi ben
<gige> SIMD even might .. would have to check
<bbogart> heya, anyone able to co the pd module from sf?
<gige> not at that level yet
<grrrr> bbogart: the devel_0_38 yes
<grrrr> although there's no console output anymore
<bbogart> grrrr: hmmmm I'm doing admins-Computer:~/work/pd-cvs admin$ cvs -z3 -d:ext:bbogart@cvs.sourceforge.net:/cvsroot/pure-data co -r devel_0_38 -P pd
<bbogart> cvs.sourceforge.net: Operation timed out
<bbogart> cvs [checkout aborted]: end of file from server (consult above messages if any)
<gige> someone willing to track the console issue down ?
<IOhannes> bbogart: just tried and it did
<IOhannes> gige: the console issue on windoze ?
<gige> yes
<gige> I doubt that its on purpose
<-- wip has quit (Read error: 110 (Connection timed out))
--> wip (~wip@Sherbrooke-HSE-ppp3609411.sympatico.ca) has joined #dataflow
<IOhannes> yes, me neither; but to get rid of the DOSbox you have to get rid of it...
<grrrr> also, i'd like to through in the pd.tk issue when no doc folder available... i would like to fix it, but i'm unable to code in tcl
<grrrr> throw*
<IOhannes> oh, what does happen ?
<grrrr> tk pukes
<msp> What I know about the console issue is... pd now calls win_main() instead of main().
<msp> This automatically backgrounds it and suppresses the console.
<IOhannes> msp: so there is not much chance to get it back
<gige> I see, we would need a detection of dos window then ?
<msp> I don't know how to give the choice,
<IOhannes> well, then i'd like to have a "log"-option which would write to a file instead of stderr
<grrrr> msp: what was the reason to use win_main?
<IOhannes> to get rid of the dosbox ?
<msp> Yep.
<msp> So anyway, anyone can just edit it back to "main()" I guess.
<msp> But I'd like a better way.
<gige> pd-gui could just stay if pd crashes . is this possible ?
<bbogart> on OSX most messages go to the console, but tcl errors and MIDI driver stuff end up in the OSX console.
<msp> Idea: there could be a "dospd.exe" that has main() instead...
<matju> msp: ok, i tried it and i agree that 2-point is sufficient for 16 bit output. (however float32 has 24 significant bits if anyone cares)
<gige> matju: people have been pondering the last 30 years about these things,
<gige> miller knows what he does, I fear.
<grrrr> ...oops, have to leave for a short time...
<msp> But.. if you want 24-bit accuracy a 2048 point table will about do it.
<msp> Maybe I should change this...
<IOhannes> and since we are at output to the console: would it be possible to add a "verbose()" thing (with setable verbosity)
<msp> I also thought about having the GUI stay up when Pd dies. Personally I prefer the
<msp> Gui to die right away so I don't have to go close it (which is what you usually want).
<matju> gige: i don't think the audio was 16-bit 30 years ago :-}
<gige> ok, if we go for high quality, I think a double version of pd would be nice.
<IOhannes> well, if anyone would use t_sample this would be easy (most of the time)
<gige> matju: yes, you are right 30 is too much for float
<Q-LogOn> back from my nice cheese sandwhich diner
<tim> msp: something that concernes me is the difference between devel_0_38 and your releases ... it's getting more and more difficult to merge changes from one branch into the other one ...
--> tigital (~tigital@pool166.dial4-clec.noc.win.net) has joined #dataflow
<gige> someone just would have to go through the pd source and use t_sample, right
<gige> its a big task, though.
<matju> gige: i wasn't talking about float, i mean even integer 16-bit audio (cd style) wasn't there 30 years ago.
--- Q-LogOn is now known as Qbert
<IOhannes> and go through all of the externals too
<gige> matju: yes that too, I was exagerating ..
<matju> gige: i think 16-bit audio is more than good enough, it's just that, usually, a cos() function is designed to fill the allocated precision, and for float32 it's more than 16 bits.
<msp> tim: yep. I went through a few months ago and merged some stuff from devel into main
<tim> e.g. the simd code is heavily connected to the audio io and the dsp tree ...
<msp> but there are getting to be formatting changes and other unneccessary differences.
<gige> matju: not if it takes input 0 to 1, its not a cos function its a wavetable synth
<msp> And yes, the simd stuff is painful to deal with.
<tim> msp: but it's fast ;-)
<msp> Yep, and speed is good. Maybe it's worth trying to make an API for replacing
<-- chokon has quit (Read error: 110 (Connection timed out))
<msp> the "c" code with other variants so external libs can install SIMD code...
<tim> i was thinking of a cleaner api for simd functions:
<gige> if we could replace the lowleve signal operations by an API, and have t_sample it would be
<gige> a lot easier to integrate PDa
<msp> For PDa you'd make t_sample be fixed point, correct?
<gige> so, I think an API only for simd is to limited
<gige> yes, its all fixed point
<tim> using function pointers for the runtime dispatching we could just export certain functions and set them at startup ...
<msp> Hmm. Here's another thing to think about... pixel ops.
<tim> this would have the advantage of a much cleaner api ...
<msp> It could turn out that different "blocks" would have different local "sample" structures
<msp> and the tilde objects would have to do a lookup.
<IOhannes> sounds very big!
--> nagasawa (~haiiro@adsl-67-124-229-84.dsl.snfc21.pacbell.net) has joined #dataflow
--> dpro (~x@test.pilot.fm) has joined #dataflow
<gige> hmm, I think this should be handeled when registering the process function
--- nagasawa is now known as twerk
<IOhannes> msp: and blocksizes not necessarity 2^n ?
<msp> Other possibility, make it compile time somehow.
<twerk> hola
<matju> gige: right... it's like when i was using a 8-bit in 8-bit out cosine table for making 320*240 video effects (that was in 1996 and i was computing the table without using the fpu, out of ideology)
<msp> Then if you're running video and audio you have to use netsend or something
<msp> to make it all work.
--> KaOz (~kaoz@p5487BA0F.dip.t-dialin.net) has joined #dataflow
<KaOz> hi
<KaOz> :)
<gige> hola twerk, ka0z and dpro
<matju> KaOz: hi. this is the first puredata developers irc-meeting.
<KaOz> interessting
<msp> Probably not the last.
<KaOz> hi
<KaOz> =D
<twerk> just wanted to get the chance to say THANKS in person for giving me amazing tools to develop with
<dpro> re all, I'm a little late loooong queue in the supermarket ...
<twerk> ;)
<msp> So... this could also imply rethinking block~ to use matju's ideas
<msp> about how to schedule computations on big blocks to get good cache behavior.
--> logreybeam (~elGeeBee@adsl-69-231-222-207.dsl.irvnca.pacbell.net) has joined #dataflow
<matju> tim: gridflow uses function-pointers for selecting operators, parametrized by "type" (4 int types, 2 float types) and "mode" (map,zip,fold,scan)
<msp> matju: I'm curious if you and Tom Schouten made any
<msp> progress
<matju> tim: loading the MMX module clobbers part of the function-pointer table
<msp> matju: I think I'm referring to your map/zip/fold/scan modes, not sure.
<matju> msp: i've been mostly hibernating this winter, as well as preparing one exhibition in Quebec City at the museum of civilisation, which will be visited by *lots* of people it seems.
<msp> Aah, civilisation, I've been there before.
<msp> Anyway, I think it would be worth thinking about opening the DSP
<matju> msp: civilisation is a lot more north... ;-)
<msp> scheduling to allow smarter ordering of execution, and maybe at the same
<msp> time make allowances for data type variation and SIMD stuff.
<matju> msp: nothing new about the operator modes in recent times, and i don't recall i promised anything about them?... do you have any ideas on improving them?
<dpro> hehe civilization in quebec SCNR
<matju> dpro: SCNR = ?
<msp> matju, yep, north, south, east, west, just anywhere except southern USA.
<dpro> sorry could not resist
<tigital> matju: (on civilization) I think it would be a good idea -ghandi
<matju> msp: must be because of the black halo surrounding all of Texanistan.
<msp> Yep. More like an oil slick.
<msp> So, anyway, maybe we have to figure out how to balance getting SIMD into the DSP
<msp> stuff with having a more forward-looking design.
--> jmisra (~jmisra@inpuj.com) has joined #dataflow
<twerk> joe
--- jmisra is now known as proswell
<proswell> hi shawn
<twerk> lurking/working
<tim> i'll rethink the simd stuff and possible do some cleanup to be able to access the functions from function pointers ...
<proswell> im still working on those wwcarpen tracks
<matju> tigital: yeah, that's a good one. Also: "The difference between this place and yogurt is that yogurt has a live culture."
<tigital> with altivec, the sad thing is, ya can't just throw in some code like mmx/sse...otherwise the "stacks will thrash"
<msp> While I'm thinking about it... here's what I'm trying to do with "data"... I want to have drawing instructions be possible to turn on and off depending on selection state and messages; also want the object to call its "struct" window back when it gets clicked.
<matju> tigital: what do you mean by thrash ?
<tigital> matju: the compiler can't figure out which register to deal with, and just freaks out
<msp> (Just figured out it's OK to do multiline on IRC)... and also, want to have screen coordinates like "loudness(0,100)(0.10)"
<matju> msp: what annoys me about the "data structures" is: 1. their name; 2. how data fields are directly bound to visual properties, with nothing one can put in between (?)
<msp> meaning (oops forgot multiline) "ranges from 0 to 100, drawn from 0 to 10".
<tigital> matju: this happens whenever you declare "vector ..." inside a non-altivec function
<matju> msp: line limit on IRC is about 250 bytes, or at least some clients still had the limit last time i checked
<matju> tigital: oh ok, there are "altivec functions" versus non-altivec ones? why so?
<tim> i'm really sorry, but i have to leave now ... i'll leave my machine up, so i can read the discussion tomorrow ... still, i hope, you'll have a productive discussion and i'll see you soon ....
<matju> tim: gute Nacht
<msp> haha.. the old 8-bit counter thing again. Anyway, I'm still not sure the whole data structure thing is ever going to be all that useful.
<tigital> matju: ask motorola?
<msp> goodnight tim and thanks...
<tigital> tim: l8r!
<msp> ... but yes, there should be some way for the data to wake up and DO stuff instead of just passively change value when dragged.
<msp> Another thing is that the placement on teh screen needs to be opened up somehow so that things don't collode all the time.
<msp> collide I mean.
<hans_> well, I must I enjoyed using the data structures for the composition I did recently
<hans_> with some work, it would be a lot better, but perhaps not what you originally had in mind
<msp> ... and thanks for giving it a spin.
<matju> msp: IRC was designed back when TurboPASCAL was king, you know. (although it still was first implemented on UNIX C, afaik...)
<msp> .. and I don't care if it's what I had in mind at first.
<hans_> I recall you coming up with the idea for making it an interactive score
<hans_> that would be very nice
<hans_> but not essential for it to being useful
<msp> well, three things. You ought to be able to play a sound in and get a clickable analysis that you could edit and paste into things.
<matju> msp: a Model/View system is much, much more configurable than the current data structs, yet is quite less complicated than a full M.V.C. model.
<msp> Then it ought to be good for interaction somehow. Finally it's a draw program fro
<msp> for making figures in the book:)
<hans_> I could see the data structures replacing the hard coded GUI objects
<msp> Does model/view mean you can use several views on a single model?
<hans_> but that might run into snarls in order to make them perform as well
<matju> hans_: i could see something better replacing both...
<msp> hans: I was actually hoping to accomplish that at first (number boxes, for instance, would just be a data structure.)
<msp> ... but it turned out lots of people wanted to use Pd before I was able to figure that out.. then Guenter made some nice
<matju> hans_: i also have rewritten the hard coded gui objects in Tcl/Tk. I'm not too sure I'd prefer the equivalent Pd abstraction, but it depends on how much pd is changed so that it's not being favouring externals over abstractions...
<msp> Guis and now I can't see getting the data to do as well as the IEM GUIs...
<matju> msp: several views on one model, normally, because one is using an Observer/Observable pattern
<hans_> well, this idea is all part of my push to have Pd be more of a programming language than an applicatoin
<bbogart> datastructurs as a set of scoped variables (rather than local s-r pairs) so that one could store arbitary data in a patch (current wise of the gem-window, etc..) and be able to retreive and set these items via name.
<hans_> Pd definitely is more of a programming language than Max/MSP, it seems to me
<tigital> matju: all my tcl/tk friends agree with yr moving the gui objects to tk: let tk do the work
<msp> bbogart: yes, I want to have a way to locally "name" data for presets etc.
<matju> msp: if M/V is ported to Pd, then outlets and send-symbols can appropriately implement the job of an observable, if 1 wire = 1 subscription.
<minDscrm> i'm out, i gotta move from one houes to another
<-- mamalala has quit (Remote closed the connection)
<msp> matju: That migth imply something semantic about connections... wouldn't you want to be able to query a connection (quite different from Pd design)?
<bbogart> I'm personally going crazy in developing pixelTANGO, running constantly into issues with the connection between tk and PD.
--> __peter__ (~peter@193.170.48.34) has joined #dataflow
<msp> Sure... I'm wondering also if it isn't too late to drop Tk and use WX instead.
<grrrr> it's never too late for that
<hans_> that sounds like a massive project for not so much gain
<msp> like quitting cigarettes.
<tigital> is wx any better? I'm not so sure
<msp> I sure like audacity (built on wx).
<tigital> fltk'd be preferred
<matju> msp: normally, part of the protocol is "add observer", "remove observer", "get list of observers", which is clear and clean in most any OOP.
<grrrr> i don't think it's about wx, but i'm dealing with the fact how to transfer processed data to the gui quickly
<bbogart> I can't tell if its tcl or simply the way the two sides are communication (mis-communicating)
<grrrr> right, fltk is better
--- __peter__ is now known as p8r
<msp> I sure don't like the "close this patch without saving?" dialog in Pd that gets it backward from all the other GUI packages...
<gige> hmm, I think the gui issue are two
<gige> one is the canvas, which probably would be best in opengl
<hans_> msp: that dialog can be changed to fit
<hans_> its on my TODO list
<gige> the other is the menu and buttons, which actually should not be that critical
<hans_> been there a while tho...
<msp> yep but the menu and buttons are 95% of the tcl code.
<matju> msp: in Pd, the atom/message/object schism is making everything more complicated. one never knows whether something is supposed to be an object or a method or an atom, it depends on how you intend to use it, whereas in most OOPs, it does not depend on that
<msp> The canvas stuff draws lines and strings and basta.
<gige> yes, but the tcl code could really need a lift
<matju> msp: (it's not as black+white as i just put it)
<hans_> indeed
<gige> and I think its not that hard,
<bbogart> I'm not sure how this realtes as well, but I'm using lots of delays to wait for certain things to finish (like dynamic patch drawing) I'm doing too many things on both sides (with tot) and it really makes tcl go out of whack.
<hans_> msp: all of the GUI objects and things like toxy would have to be totally rewritten
<gige> and the lines and strings would be fast and scalable in opengl
<gige> yes, toxy yes
<gige> and the gui, .. hmm
<msp> bbogart: I find sometimes I have to ping the GUI side from Pd to make sure everything is in sync.
<hans_> I am a big fan of toxy :)
<msp> It's hard to get it right in general.
<gige> logreybeam: hi from bram
<matju> msp: so, whether outlets should be used, or pointers, and whether queries are necessary, are Pd-only issues, and frankly, they can apply to a damn lot of functionality. Jitter has the right-outlet of every object reserved for querying, and although I'm just beginning to do the same with GridFlow, I'm hesitating because I think it sucks
<tigital> but just saying opengl isn't enough: we still need to go thru glut/glx/fltk/wx/sdl/whatever
<gige> yes, thats right, that was the second part of the two fold problem
<msp> matju: right. I'm wondering the same thing about "pointers" which maybe should have been backward connections.
<tigital> k
<msp> I really like how "xeq" worked out that way.
<matju> msp: actually my other idea was that, instead of sending "get colour" in the left-inlet and getting a float out of the right-outlet, it would be "get colour $1" where $1 is a pointer, and then the pointee would receive a message directly.
<grrrr> oh wow... flext is heading for that
<msp> Yep. I
<msp> .. almost already made "table" do that once. "Value" too.
<matju> msp: that is, that would be a message-with-reply, as found in a bunch of RPC/RMI/mailbox/microkernel architectures, to match the fact the return-value concept is useful.
<msp> Yep. the lack of a way to return stuff is one of the biggest problems in Pd.
<logreybeam> Bramster
<logreybeam> :)
<matju> msp: it's a basic problem in mostly all dataflow architectures, because they are designed to make *all* data flow explicit, which incidentally means return-values automatically need double-arrows of some kind.
<-- wip has quit (Read error: 110 (Connection timed out))
--> bbogart_ (~bbogart@215.dialup.ccs.ryerson.ca) has joined #dataflow
--> wip (~wip@Kitchener-HSE-ppp3570884.sympatico.ca) has joined #dataflow
<msp> yep.
<logreybeam> mr puckette.. mad respect, and gratitude
<logreybeam> worktime....
<bbogart_> crap, connection dropped.
<msp> logreybeam: HAve a cool workday...
<-- bbogart has quit (Read error: 104 (Connection reset by peer))
<logreybeam> hehe.. do me best:) thanks
<matju> msp: i think a class [q] would have one inlet such that "get colour" would be sent as "get colour $1" left, where $1 is a pointer to [q], and when it's done, right-outlet would output the return-value.
<-- twerk has quit ("reboot")
<gige> logreybeam: yes, bram was just standing beside me and he told me to say hello and that he likes your
<gige> music
<matju> msp: i mean [q] would be a bridge between replyful objects and replyless objects
<msp> Funny, I actually did that in Max in 1988.
--> alejoo (~tanks@191.Red-80-34-144.pooles.rima-tde.net) has joined #dataflow
<logreybeam> yay! working on my john carpenter cover rite now:) big trouble in little china
<msp> It gave me some kind of pain though, I don't remember what.
<logreybeam> give bram a hug for me:)
<msp> specifically, for a month or so there was a "pointer" object with two outlets.
--> mamalala (~root@dsl-082-083-050-079.arcor-ip.net) has joined #dataflow
<msp> You "banged" it and out the left outlet cam a usable POINTER to whatever was on the right one!
<gige> logreybeam: I will
<msp> Then you could bash or query it all you wanted to.
<msp> Perhaps what you're suggesting is a bit better than that though.
<matju> msp: that's a "reflection" kind of feature!
<matju> msp: it looks at the outlet and the wire, instead of just blindly sending through it =)
<matju> msp: i mean your solution. mine doesn't have a use for peeking into the t_outlet itself
<msp> Yes, although you could implement it by sending a "probe" message down the wire.
<msp> This is probably what "xeq" does, not that I think of it.
<matju> msp: reflection features, like what's available in dyn, pyext, and pd itself, are important, because they compensate for the atom/object opposition that atoms flow around and objects don't.
<msp> hmm, that's a good characterization. Real-time probably means "only little things can run around, big ones stay put".
--> pmdboi (~pmdboi@12-202-241-108.client.insightBB.com) has joined #dataflow
<grrrr> dyn tries to circumvent that....
<matju> msp: reflection is "less useful" in other languages, but still, it's getting fashionable these years, in the realm of all those languages that need it less
<msp> matju: is there a simple discussion of the idea I can read?
<matju> msp: hmmmmmmmmmm? who's talking about real-time-specific things here?
<msp> I mean "reflection", not "real time"
--- bbogart_ is now known as bbogart
<matju> msp: the first i'm thinking about is: http://c2.com/cgi/wiki?MetaProgramming
<matju> msp: c2.com is the oldest wiki on earth and also an excellent source of OOP/XP concepts/discussions
<msp> cool, will check it out.
<Qbert> msp: got an offtopic question, what latex package do you use to go from tex2html?
<msp> latex2html, but I think there are better ones now.
<Qbert> ok thansk
<Qbert> thanks for the new chapter btw
<-- msp has quit ("using sirc version 2.211+KSIRC/1.2.4")
<Qbert> oh bye
<Qbert> oh noo, i scared msp away
<Qbert> :(
* Qbert goes to hide in corner
--> msp (~msp@musicsf2.ucsd.edu) has joined #dataflow
<matju> did he say he'd leave, or did he just click "X" instead of "Ok" ?
<Qbert> welcome back
<matju> ah, he's back
<msp> Just tried to #&$%#^ copy matju's URL so I could chase it later. Lost everything.
<matju> msp: http://c2.com/cgi/wiki?MetaProgramming
<Qbert> ok im off to work bye, (ill read the log :)
<msp> Thanks. But now I'll just type it by hand.
<jtm> as a PD newb it's really refreshing to see msp struggling with irc ;)
<matju> that whole wiki is quite interesting. it's run by a bunch of Smalltalk programmers with too much experience. ;-)
<matju> msp: you crashed it, or just closed it by accident?
<msp> yep, but I'm finding it a lot easier than I think it is to learn Pd. I tell people to expect a year-long learning curve,
<msp> but my own has been more like 20.
<matju> LOL
<msp> Crashed it.
<matju> msp: actually we are using xchat; i learned that alx switched to xchat many months ago.
<matju> msp: xchat seems better-done
<msp> yeah, but it didn't start up for me.
<msp> Doesn't matter.
<proswell> year long learning curve seems about right
<msp> Yep, six months to start making good sounds, and then another six to get the "clicks" out.
<matju> msp: i'm thinking that after a 4-year learning curve of jmax/pd i'm still not nearly at the level of comfort i'm at in ruby or even in tcl
<matju> msp: i expect that the "learning curve" will prolong itself by a "rewriting curve"
<matju> or "reconceptualisation curve"
<msp> That's because you're trained as a mathemetician. THey expect things to be logical...
--> wip2 (~wip@Sherbrooke-HSE-ppp3611954.sympatico.ca) has joined #dataflow
<matju> msp: well, i originally trained myself as an ad-hoc BASIC/LOGO programmer as soon as i stopped sucking the pacifier
<msp> Right, I think BASIC came out of the Dartmouth math department and LOGO from Seymore Papert (AI-ish)
<matju> msp: it's not nearly as stuck-up as a math bacc
<-- logreybeam has quit (Read error: 60 (Operation timed out))
<msp> (I started with BASIC too, and I don't think it's all that bad as a starter language.)
<matju> msp: haha, well, the language you start with is one that you are not harsh with, especially *because* it's the one you first used.
<matju> msp: i *learned* to hate BASIC, but it took me too much time.
<gige> he, I have to go, ... whatever turns out of this, it was a nice experience .. bye
<matju> gige: bye
<IOhannes> bye guenter
<-- gige has quit ("Leaving")
<msp> bye and good noght.
<msp> night I mean.
<matju> Nacht ?
<IOhannes> yes
<IOhannes> nocht
<IOhannes> but back to the basics: i guess most of us (not so) youngsters started with it
<IOhannes> and still, few people "like" it
<IOhannes> (although i too think that is is ok for a start)
<IOhannes> (but probably nothing but a start)
<msp> Yep. Not likely to rewrite Pd in basic.
<matju> going back to BASIC is about as fun as the thrill of punching one more FORTRAN-IV program by hand just for the retro effect
<jtm> it's a great way to leave a fun message on your friend's apple][ that would scroll up and down the screen.
<IOhannes> msp: but this reminds me
<-- wip has quit (Read error: 104 (Connection reset by peer))
<IOhannes> i just got an old amstrad cpc6128 (z80a) and i would love seeing pd on it
<IOhannes> since locaomotive basic is builtin, that would be my choice...
--> wip (~wip@Kitchener-HSE-ppp3572358.sympatico.ca) has joined #dataflow
<IOhannes> "locomotive" it was
<msp> easy. Write a PC simulator in BASIC.
<jtm> haha
<matju> IOhannes: i will get a 6809 with 512K RAM and MicroWare OS9 (from those who sued Apple over the name or something)
<hans_> lol
<msp> Then load linux and install Pd.
<IOhannes> ah thanks for the hint: a
<jtm> might not be as snappy as you'd hope
<IOhannes> well, they have built an mp3-mplayer for the cpc and it works with probably 25% (a bit of hardware and a bit of vaporware, who knows)
<matju> MW-OS9 is much like QNX, both are realtime microkernel unix-alike, but OS9 was found mostly on TRS-80 Color Computers
<IOhannes> so there is some hope...
<IOhannes> 25% CPU-load, that's what i meant
<wip> hi msp, i was wondering if pd 0.39 will support loading samples without dropping the sound?
<jtm> how do you guys feel about having hardware modules dedicated to PD?
<IOhannes> jtm: like ?
<msp> wip: I think the "devel" branch does that, but otherwise, the only way is to make a patch using readsf~ to load
<msp> samples.
<matju> jtm: mamalala (C Klippel) is making such hardware modules.
<mamalala> IOhannes: the mp3player could be possible, there are dedicated, small mp3 decoder chips available, just hook that on a bus, and youre done ... even a parport can do ...
<jtm> IOhannes like a handheld device that has multiple sliders/buttons or whatever you decide, audio I/O and a usb or ethernet port to load custom built patches
<mamalala> like this one: http://www.vlsi.fi/vs1002/vs1002.htm
<jtm> matju: yes, like that but his idea is more to emulate some existing interfaces
<wip> jtm: his next project will use this (if he have enough money) http://www.dilnetpc.com/index.html
<jtm> wip: yes, mamalala turned me onto the dilnet site, it seems like a reasonable starting point
<matju> jtm: http://multio.mamalala.de/
<msp> Anyhow... I have to go to another kind of meeting now... this was very useful to me (and thanks matju for setting this up..)
<bbogart> something like teleo?
<wip> msp: thanks
<matju> msp: when should the next meeting be?
<jtm> i'm more curious how you folks felt about hardware being dedicated to PD
<tigital> msp: cya
<jtm> bye mr. msp
<IOhannes> msp: we missed the fft-nyquist discussion
<IOhannes> msp: anyhow, all the best
<alx1> msp: thank you
<mamalala> msp: bye !
<msp> (looking in book...) I'm free most Friday mornings if that works for the rest of you...
<jtm> msp: the command is '/quit' :)
<mamalala> jtm: what you mean with "more didacted to pd" ?
<msp> (I think this was 10AM PST, 1700 UTC).
<IOhannes> msp: friday morning, is this now ?
<tigital> it's always good to poke your head in...
<jtm> mamalala: i don't think i said "more"
<IOhannes> ah yes, i think it is quite ok for me (being almost UTC)
<jtm> mamalala: i was trying to find out how the PD developers felt about the idea
<msp> ... and anyhow, what frequency would be good... biweekly perhaps?
<mamalala> jtm: then, with just "dedicated" ... ;)
<IOhannes> yes probably
<jtm> mamalala: like the devices we discussed in depth 2-3 days ago
<IOhannes> msp: but not more often
<mamalala> ah, ok ...
<msp> I dunno... if people think more frequent is better I can handle it. I don't want everyone to start thinking it's a chore.
<mamalala> msp: i am planning to make some stand-alone unit, like a mc-505 or such, but running software like pd (imagine some open-sourced nord-modular with just a fancier ui)
<matju> msp: i think california mornings will be excellent, because then it's afternoon in montreal/ottawa/ny/ky, and evening in es/de/at
<matju> msp: i mean what i hope is to organise it at reasonable times for everyone, no 4 AM's
<tigital> agreed
<IOhannes> yes, so 18UTC is fine for anyone but andrey (probably) and the australian people
<msp> Yeah. Anyhow, do people prefer next week, or week after next???
<IOhannes> i will most probably not be online in 2 weeks
<p8r> yes
<msp> Also, what time is it RIGHT NOW in UTC???? I think it should be 2100.
<IOhannes> now it is 20:00
<msp> Thanks...
<matju> msp: i recall that a similar meeting occurred when this channel was called #jmax, several years ago. we had people from ottawa, montreal, paris (ircam), deutschland, and _australia_. what a timezone-mess
<IOhannes> it is 21:00 CET (thats me)
<msp> SO 1800 UTC in 2 weeks OK>
<IOhannes> SO like sonntag (sunday) ?
<IOhannes> anyway...
<matju> msp: it was supposed to be 1700, but the 1800 was because i knew you'd be late
<matju> msp: is 1800 better for you in the future ?
<msp> Freitag/friday, March 11
<-- wip2 has quit (Read error: 60 (Operation timed out))
<msp> ... and I might have another thing at 1700 then, but maybe not...
<msp> Anyhow, signing off now. Thanks for all the info!
<matju> msp: i was about to suggest march 18th, but 11th is also fine with me. both are ok as we have some catching up to do
<IOhannes> i'll not be there (visiting family)
<matju> msp: i mean we had planned to make more meetings than that
<msp> OK... but 18th OK?
<IOhannes> i'll not be there on march 11, i mean
<IOhannes> matju: but any second meeting will be "more meetings than that"
<msp> Let's do 18th then, not 11th.
<IOhannes> would be great for me (i think)
<matju> msp: btw Zack Settel works in Montreal. you recall him ?
<msp> ...anyhow, now late for next thing.... talk to you all soon. -Miller
<matju> msp: bye
<-- msp has quit ("using sirc version 2.211+KSIRC/1.2.4")
<IOhannes> bye bye gone
<hans_> time for me to sign off as well.
<hans_> talk to you all soon
<p8r> bye hans_ !
<tigital> yeh, back to work fer me
<IOhannes> see you then
<alx1> hans_: cya, DiVA in two weeks
<matju> alx1: what's DiVA ?
<alx1> hans_: let me know if you want tickets
<p8r> tigital: bye jamie!
<alx1> matju: digital and video arts fair at a hotel in manhattan
<tigital> l8r p8r
<hans_> alx1: I might, I'll let you know
<IOhannes> bye peter
<p8r> tigital: hehe! got that from you :-)
<p8r> IOhannes: seas!
<IOhannes> und jetzt ?
<p8r> IOhannes: MKL?
<IOhannes> na, ich gehe jetzt schlafen; morgen rijeka
<IOhannes> was ist im mkl
<-- hans_ has quit ()
<p8r> IOhannes: bin eh in wien (bett und krank) hast du urlaub?
<IOhannes> ja (aber ich habe vergessen und heute die gerda aufs iem bestellt...)
<p8r> IOhannes: helf ich ihr :-)
<IOhannes> apropos MKL: alex, is the bench still here ?
<IOhannes> p8r: zu speat
<-- tigital has quit ()
<alx1> IOhannes: the box you mean? I have been trying not to bother Franz too much
<p8r> i think the bench went back but not the suicase
<p8r> suitcase
<alx1> Franz has not given me a tracking number
<IOhannes> ah, i thought you were afraid of breaking the screen a second time
<p8r> alx1: then bither him :-)
<p8r> bother
<alx1> I have another version of it here but I would prefer to show the one that was in graz (with a repairded screen)
<alx1> p8r: sure I call him every now and then
<matju> krzYszcz: you seem very quiet
<IOhannes> oh
<IOhannes> anyhow, i think i will leave now too
<IOhannes> who did logs ?
<IOhannes> (how do you do this with xchat ?)
<jtm> IOhannes
<IOhannes> jtm
<p8r> matju usally does ( you can make logs with ksirc afaik)
<jtm> care to comment on dedicated hardware for pd
<jtm> once before you leave?
<IOhannes> oh, sorry i forgot:
<jtm> i can give you a checkbox form
<IOhannes> ok
<jtm> interesting [] uninteresting []
<jtm> :)
<matju> none of the above []
<matju> mu []
<jtm> haha
<jtm> true
<IOhannes> lol
<matju> excluded middle fallacy []
<IOhannes> well, i think why not ?
<jtm> /part []
<jtm> ok
<IOhannes> it is not a really big concern with me (on the other hand, i do some "custom hardware" to be controlled by pd too)
<matju> Kurt Gödel would have us add: undecidable []
<IOhannes> but it is very "custom made" (nothing special, but i am not good at soldering)
<jtm> IOhannes and matju: i'm just curious if the developers would think of dedicated PD hardware as a waste of an otherwise multi-functional computer
<IOhannes> i think this is totally dependent on the project you are doing.
<jtm> well i think we agree then
<IOhannes> probably i will not play mp3s from a dedicated hardware if i have a pc and plenty of cpu-cycles
<matju> jtm: here's my pd-dedicated hardware: http://artengine.ca/matju/baaad_hak.jpg
<jtm> matju: that's beautiful
<matju> jtm: a resistor, a transistor, and two paperclips.
<IOhannes> bmatju: looks like mine
<mamalala> matju: whats that ? a dongle for pd ? ;-D
<IOhannes> who had this projects of pd on ASICs (or whatever) ?
<mamalala> or for gridflow ...
<IOhannes> i liked that one
<alx1> matju: :-), reminds me I have to solder a proper connector for the camera!
<jtm> IOhannes did someone have a working project of pd running on ASICs?
<IOhannes> dunno, i have forgotten the link and what it was about
<jtm> ok
<matju> mamalala: hehe. it's a way to make a hardware [tgl] with Pd.
<matju> mamalala: using other voltage conventions, i also have some with just wires plugged directly in. and of course, paperclips again.
<IOhannes> jtm: cyrille once sent me (and tom) the link, but i cannot find it now
<mamalala> matju: haha ..... nice ....
<matju> mamalala: i've also connected the [tgl] a Nintendo Zapper (1985) in a parallel port using one big-ass paperclip that fits tight in the holes of the connector
<jtm> that's ok IOhannes, i'll keep looking around for others (like mamalala)
<IOhannes> jtm: i found it, it is http://www.glui.de which you probably know and which has nothing to do with ASICs#
<IOhannes> anyhow by p8r, matju, alx, jtm, x, ben and everyone else
<IOhannes> by should be bye
<jtm> IOhannes: never looked there before, looking now
<jtm> by bye
<jtm> :)
--> ianp (~ian@inpuj.com) has joined #dataflow
<-- IOhannes (~IOhannes@d-104.dsl.tu-graz.ac.at) has left #dataflow ("weaving")
<ianp> wow, big crowd
<jtm> ;D
--- matju has changed the topic to: The Diagram Is The Program (tm) | PureData Montréal Users Group has meeting #7 this saturday 26th, 13:00, 8257 StDenis, métro Jarry.
<Pio> is that really trademarked?
<matju> ianp: six people have left since the peak at 32 people.
<alx1> matju: are going to post the logs?
<matju> Pio: i claim a trademark on it, although it's not registered (i don't _need_ a registration)
<jtm> post the logs and parse it line by line to remove anything containing 'jtm' :P
<Pio> right on matju
<matju> Pio: i came up with that slogan a year ago or so, when i got tired of the former one "Ohm is where the art is"
<Pio> its a great one, ive explained puredata to several people by citing it
<matju> Pio: wow, cool!
<alx1> I tried dpro's 'pinkdada' with little success
alejoo alx1
<-- alejoo has quit ()
<matju> alx1: well, not really comparable, it's not a slogan, it's just a funny word.
<proswell> ian you missed the meeting
<Pio> i was just explaining PD to my mom actually.. and im like 'their slogan is ____' and she was all Ohh neat! heh
<matju> alx1: also, i'd rather prefer pinkdada to not become a popular word, especially because it reinforces the sound of "pd" in french...
<alx1> matju: the comparison is in the original dada form though
<alx1> nonsensical that is
<matju> Pio: it's really mine and not miller's. i mean especially, the people on the pd-list don't know that slogan, except when they know this channel
<Pio> i'd seen it on some random site in the pd webring before i found this chan
<matju> alx1: try purple data. it's not the same rhythm, but that's an occasion to be creative and give it a funky beat
<matju> Pio: really?...
<jtm> matju: i didn't know you coined that phrase. it's elegant
<alx1> it needs to have dada in it
<matju> Pio: my homepage isn't in the webring; gridflow.ca _is_ in the webring, but doesn't have the slogan on it.
<matju> alx1: er. i wanted to say purple dada. also is p.d. and also has a colour name
<matju> jtm: thanks
<matju> I'm also proud of coming up with the name GridFlow, and even though the name is not completely unique, it's more meaningful than the two former names it has had...
<p8r> tell us pleeze
<matju> p8r: hmmm?
<p8r> the two former names of gf
<matju> versions 0.1 - 0.4 were called Video4jmax
<matju> the name had two problems:
<matju> 1. "video" - not just video
<matju> 2. "for jmax" - not just jmax
<p8r> the others?
<matju> from then it didn't take me long to do non-video, but non-jmax had to wait 1-2 years more. (1 year to have the guts, 1 year to have the debugging skills)
<matju> GridFlow 0.0 was called with a name closer to "GridFlow" in spirit: STAR, standing for STreamed ARrays
<matju> streamed as in flowing
<matju> and arrays as in grids
<matju> ironically, it took until version 0.2 to get grids.
--> chokon (~asds@212.145.121.193) has joined #dataflow
<chokon> hi
<chokon> is it possible to make streaming video with pure data?
<jtm> chokon: make?
<chokon> to stream video
<chokon> with pure- data
<matju> chokon: from one machine to another ? use pidip/ffmpeg. (but apparently it's difficult to install)
<matju> chokon: else, almost everything in GridFlow streams from one object to another ;-) (true!)
<jtm> yeah i think people have done it from one PC to another, but do you mean over the internet?
<chokon> but can i make a stream for 10 persons?
<matju> chokon: it depends on what ffmpeg can do; read about ffmpeg and you'll know.
<chokon> ok thanx
<alx1> matju: I would want to pass an image from GF (in uint8 rgb format) to a c function that expects (image, width, height), what should I do within GF?
<matju> alx1: you could write a GF object in C++ although this can be slightly hard... i can help you with that.
<matju> alx1: have you sent me a copy of artag ?
<alx1> matju: yes I did just send you another one
<-- chokon has quit ()
<alx1> matju: but why c++ instead of ruby?
<matju> alx1: because you're connecting together C code to GridFlow and almost nothing else, so there is no point in directly using Ruby
<matju> alx1: unless you can make Ruby/DL (require "dl") do all your job ;-)
<-- krzYszcz has quit ("Leaving")
<matju> alx1: to understand how to receive a grid in Ruby, you can look at the source of #print.
<matju> alx1: for C++ you can look at just [#].
<alx1> matju: ok, and you have the same shortcuts for outlets in C++ (send_out 0 and the like)?
<matju> alx1: if i'd do it myself, i'd detect artag in ./configure and add a .c file in optional/
<matju> alx1: not the same shortcuts no, ... and not enough shortcuts.
--> arkadyan (~arkadyan@h000c41435257.ne.client2.attbi.com) has joined #dataflow
<matju> alx1: i mean, to call send_out you need to go through Ruby using rb_funcall()
<matju> alx1: btw i prolly already had artag, but it's just that i can't remember the content of all 200 pending mails, you see.
<bbogart> later all, time to work on my CC grant.
<-- bbogart has quit (Read error: 54 (Connection reset by peer))
<matju> alx1: and yes, i reply to old mails, because i want to make sure i close all old issues as well.
<alx1> matju: that's cool, i understand
<-- grrrr has quit (Nick collision from services.)


Powered by IEM Powered by Plone Section 508 WCAG Valid XHTML Valid CSS Usable in any browser