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

dev@irc 05/2

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

logfile of the 2nd dev-meeting @ IRC on 18.03.2005 as found on http://mis.is-a-geek.org/~mis/Mar18-05-dataflow.log

Mar 18 12:00:11 <mindftom> ah nice....
Mar 18 12:00:20 <mindftom> so i can draw shit in a table and it comes out as audio ?!!?
Mar 18 12:01:30 <mindftom> for isntance i want to draw filtergraphs .. can i do that with convolution?
Mar 18 12:01:39 <dpro> yes
Mar 18 12:01:48 <mindftom> i want to draw my eq's filtergraph into a table and have that be a the eq settings
Mar 18 12:02:31 <dpro> du you have iemlib/abs installed ?
Mar 18 12:02:50 <mindftom> hmm..
Mar 18 12:02:52 <mindftom> i dnno
Mar 18 12:02:59 <dpro> then look at help-FIR~.pd
Mar 18 12:03:10 <mindftom> yea i do
Mar 18 12:03:13 <mindftom> alright
Mar 18 12:03:39 <mindftom> ah i read help-FIR~ .. shit makes no sense, but i'll read it agian
Mar 18 12:04:13 <dpro> just draw into the coefficient array for filter painting
Mar 18 12:04:22 <mindftom> ok
Mar 18 12:04:35 <dpro> http://www.dspguide.com/filters.htm
Mar 18 12:05:05 <dpro> hope you run 0.38 otherwise you'll get lots of clicks when drawing in arrays
Mar 18 12:05:43 <mindftom> ah rad, i run .38
Mar 18 12:05:56 <mindftom> er.. i run .39
Mar 18 12:06:18 <mindftom> i run 0.39 i guess
Mar 18 12:06:59 <mindftom> i guess it's okay in 0.39 ?
Mar 18 12:07:27 <dpro> well at least 0.38 (then again 0.38.3 is latest so you have a future version ;)
Mar 18 12:07:42 <dpro> o.38.4 sorry
Mar 18 12:07:52 <mindftom> ah, i'm a crack head i gues si dunno what i'm doing
Mar 18 12:07:55 <mindftom> i'm from the future anyway
Mar 18 12:08:12 <mamalala> haha.....
Mar 18 12:08:15 <mindftom> i'm from 2030 , but i'm retarded so i'm stuck here.
Mar 18 12:14:27 <mindftom> what is abs standfor ?
Mar 18 12:14:32 <mindftom> abstract math?
Mar 18 12:16:47 <mindftom> just rashed pd
Mar 18 12:16:48 <mindftom> fun
Mar 18 12:17:20 <dpro> mindftom: abs-olute
Mar 18 12:17:28 <mindftom> ok
Mar 18 12:20:22 <mindftom> that's pretty easy .. that FIR thing
Mar 18 12:21:47 <mindftom> that would be rad to go through tables like a mad man changing the filters on shit as fast as possible
Mar 18 12:21:49 <mindftom> whole tables
Mar 18 12:22:23 <mindftom> or sets of tables to create 'beats'
Mar 18 12:22:44 <mindftom> er.. i guess to create patterns.. which in turn may end up creating beats or rythms
Mar 18 12:22:48 <mindftom> however you want to look at it
Mar 18 12:22:53 <mindftom> that's rad, thanks alot dpro
Mar 18 12:23:16 --- mindftom is now known as minDfrqnc
Mar 18 12:34:08 --> bbogart (~bbogart@243.dialup.ccs.ryerson.ca) has joined #dataflow
Mar 18 12:40:45 --> Miller (~msp@ca-encin-ar06-millerpuckette-229.adnc.com) has joined #dataflow
Mar 18 12:40:59 <minDfrqnc> rock on, heya msp
Mar 18 12:41:32 <Miller> hi all... sorry, trying to learn new IRC client, haveto find a readabe font now.
Mar 18 12:41:44 <minDfrqnc> fixed width fonts rock
Mar 18 12:42:37 <Miller> yep. Have to find where I _set_ the *$&% font.
Mar 18 12:42:41 <-- pmdboi has quit (Read error: 60 (Operation timed out))
Mar 18 12:45:23 <chikun> :O)
Mar 18 12:45:26 <bbogart> brb
Mar 18 12:45:27 <minDfrqnc> dpro, are you still here?
Mar 18 12:45:36 <minDfrqnc> is there a meeting today?
Mar 18 12:45:48 <minDfrqnc> ah crap
Mar 18 12:45:49 <chikun> miller , are u miller puckette?
Mar 18 12:45:57 <minDfrqnc> that' means i can't ask moronic questions any mor
Mar 18 12:45:59 <minDfrqnc> more
Mar 18 12:46:12 <Miller> yep. Still flailing with xchat...
Mar 18 12:46:23 <chikun> cool
Mar 18 12:46:42 <minDfrqnc> one more question before you guys start up..
Mar 18 12:47:27 <minDfrqnc> with [FIR~ fir_coeff 256] ... what does the 256 mean?
Mar 18 12:48:05 <minDfrqnc> i guess it means the fir_coeff, but i don't know what that means either heh
Mar 18 12:48:28 <minDfrqnc> nevmerind, i'm not gonna embarress myeslf anymore i guess. you guys got better things to do
Mar 18 12:48:42 <chikun> miller do u use drugs?
Mar 18 12:49:08 <Miller> just poured another cup of strong tea right now.
Mar 18 12:49:26 <bbogart> Hi Miller
Mar 18 12:49:42 <mamalala> hi Miller, hi bbogart
Mar 18 12:50:04 <Miller> hi ben, mamalala.
Mar 18 12:51:31 <minDfrqnc> yea i do
Mar 18 12:51:34 <bbogart> Hey Christian
Mar 18 12:51:38 <minDfrqnc> er crap nm
Mar 18 12:51:52 <mamalala> bbogart: long time no see, uh ? ;-)
Mar 18 12:52:22 <bbogart> mamalala, an eternity! ;)
Mar 18 12:54:26 --> alx1 (~alx@HSE-Kitchener-ppp230013.sympatico.ca) has joined #dataflow
Mar 18 12:54:39 <mamalala> hi alx1
Mar 18 12:54:39 <alx1> hi all
Mar 18 12:54:45 <wip2> hi alx1
Mar 18 12:54:52 <bbogart> hey Alex, how are you?
Mar 18 12:55:17 * number np: shining - gortex weather report
Mar 18 12:55:44 <wip2> bbogart: nice, thomas want to include v3 to pixeltango. now we just have to know how
Mar 18 12:55:44 <alx1> bbogart: not bad, I was just with Andree talking about artengine projects
Mar 18 12:56:32 <wip2> alx1: i have an overhead projector and i'm looking for a lcd panel to put on it. maybe you have something laying around?
Mar 18 12:56:35 <bbogart> Alex: yeah, she is really trying to make the project happen!
Mar 18 12:56:44 <matju> Miller: hi.
Mar 18 12:57:04 <Miller> Hi matju...
Mar 18 12:57:06 <alx1> wip2: not yet
Mar 18 12:57:17 <wip2> alx1: k
Mar 18 12:58:05 <alx1> bbogart: I will take some images of the new artengine space tonight
Mar 18 12:58:14 --> IOhannes (~zmoelnig@iem.kug.ac.at) has joined #dataflow
Mar 18 12:58:22 <IOhannes> shit
Mar 18 12:58:24 <mamalala> hi IOhannes
Mar 18 12:58:27 <IOhannes> hi
Mar 18 12:58:35 <alx1> IOhannes: ?
Mar 18 12:58:40 <bbogart> Alex: you have a space!!!!!!!!!!!!!!! congrats!!!
Mar 18 12:58:54 <IOhannes> i should be at home instead of at work, and i think i won't make it anymore...
Mar 18 12:59:09 <IOhannes> but at least i am here
Mar 18 12:59:13 <alx1> bbogart: thxs :-), actually two a lab and a bar
Mar 18 12:59:15 <dpro> hi all
Mar 18 12:59:32 <IOhannes> hi x
Mar 18 12:59:55 <bbogart> alex: wow!!! I'm very exited for you! IA is moving May 1st going up to 3000sqft!
Mar 18 13:01:52 --> krzYszcz (krzYszcz@dqn93.neoplus.adsl.tpnet.pl) has joined #dataflow
Mar 18 13:02:04 <mamalala> hi krzYszcz
Mar 18 13:02:06 <alx1> bbogart: sweet, here are the specs for the club -> http://www.mercurylounge.net/tech_specs/tech_specs.html
Mar 18 13:02:20 <bbogart> Miller: any ideas about the doc/ folder discussion?
Mar 18 13:03:17 <Miller> I haven't thought carefully about it... I think if people are going to assemble large collections of stuff from different places the doc has to be where the stuff is.
Mar 18 13:03:29 --> pmdboi (~pmdboi@pcp0010179204pcs.columbus.in.indy.comcast.net) has joined #dataflow
Mar 18 13:03:42 <Miller> I wonder if Max deals with this problem adequately.
Mar 18 13:04:12 --> andree (~andree@modemcable031.253-81-70.mc.videotron.ca) has joined #Dataflow
Mar 18 13:04:31 --> _hc (~purecanes@user-0cdf4hn.cable.mindspring.com) has joined #dataflow
Mar 18 13:04:37 <chikun> miller is wierd to see u chatting, i always think of u like a pop star or genoius or spirit, now i can see u are a human
Mar 18 13:04:39 <mamalala> jmax used to carry the documentation of externals in the external's directory, together with the actual external/abstraction ...
Mar 18 13:04:40 <andree> Hi everybody
Mar 18 13:04:44 <bbogart> Miller: I agree that doc/ is the place. I don't remember exactly how MAX dealt with the problem, in the object list box?
Mar 18 13:04:47 <bbogart> hi Andree!
Mar 18 13:04:53 <pmdboi> whoa... mr. puckette is online
Mar 18 13:04:55 <pmdboi> this is cool
Mar 18 13:05:01 <andree> Hi ,ben
Mar 18 13:05:23 <bbogart> Alex: wow, I'm really looking forward to pictures. And the lab part?
Mar 18 13:05:24 <Miller> I _think_ that's the way Pd does it (the jmax way).
Mar 18 13:06:00 <mamalala> Miller: that would mean, to load an external it would just suffice to give its base directory as option to pd ?
Mar 18 13:06:01 <chikun> : /
Mar 18 13:06:20 <Miller> Perhaps a mechanism is needed to make deep searches of a 'standard' place (extras?) where you could mix hierarchies of externs/doc.
Mar 18 13:06:22 <pmdboi> i thought the docs for the externals got installed in $pdpath/doc/5.reference as it is
Mar 18 13:06:33 <pmdboi> with the docs for the built-in objects.
Mar 18 13:06:53 <pmdboi> makes the menu pretty crowded, though.
Mar 18 13:06:56 <Miller> yes, but that's before there were large numbers of externs...
Mar 18 13:07:13 <mamalala> ok ....
Mar 18 13:07:27 <_hc> so I have two questions about a possible hierarchy
Mar 18 13:07:37 <alx1> bbogart: we have a hdsp 9652 :-) and a lot of space.
Mar 18 13:07:38 <Miller> In fact, if doc were done hierarchically, I could separate 5.reference functionally
Mar 18 13:07:39 <bbogart> Miller: The idea of putting doc and external beside one and other is interesting
Mar 18 13:07:41 <_hc> what would be the organizing principle, and how do we enforce it?
Mar 18 13:08:20 <Miller> Well, maybe just extra/package-name/functional-group-name.
Mar 18 13:08:29 <_hc> I think if someone was browsing for a help document, then you'd want it organized by functionality
Mar 18 13:08:40 <_hc> but that means someone has to organize all those help files...
Mar 18 13:08:58 <IOhannes> but that would mean categorizing and i don't see a way to do that automatically
Mar 18 13:08:59 <bbogart> HC: One central idea of organization would be problem solving. The user needs an object that does ____ Create an image? Work with Control Data? Midi? FFT? catagories to cluster the vast numbers in navigable peices.
Mar 18 13:09:40 <IOhannes> and it would again reinforce the problem of (possible) nameclashes ;-)
Mar 18 13:09:53 <pmdboi> maybe one could do something similar to apropos, but for externals instead of unix programs?
Mar 18 13:09:56 <IOhannes> which does not arise with extra/<packagename>
Mar 18 13:09:57 <bbogart> Johannes: depends on the Catagories... I think most would say that zexy would not fit into the visual catagory. There always is grey area this is true.
Mar 18 13:10:30 <pmdboi> make all the external writers add an object to the top level of the documentation called, say, "description" with the description of the object passed as arguments
Mar 18 13:10:34 <_hc> I think we need to deal with nameclashses anyway
Mar 18 13:10:34 <IOhannes> yes, but what about "general purpose" things as cyclone ?
Mar 18 13:10:37 <bbogart> I'm not sure much thinking of external organization, as external documentation & example organization
Mar 18 13:10:39 <Miller> the 'apropos' idea (aka 'man k') might be good.
Mar 18 13:10:47 <pmdboi> and then have something like "makewhatis" that slurps all the about data from the help files and makes a database
Mar 18 13:11:05 <bbogart> if we could search for keywords in a patch's comments that would be a good clue to its functionality...
Mar 18 13:11:05 <_hc> pmdboi: an automated pdb
Mar 18 13:11:15 <IOhannes> so this goes into the automagic doc-generation ala doxygen ...
Mar 18 13:11:25 <_hc> my thoughts exactly
Mar 18 13:11:27 <Miller> Or how about an "00_intro" file in each directory?
Mar 18 13:11:42 <IOhannes> isn't this standard anyhow ?
Mar 18 13:11:48 <_hc> somewhat
Mar 18 13:11:56 <bbogart> What does the 00_intro contain? (in each catagory directory?)
Mar 18 13:12:01 <IOhannes> but still you would have to search through a lot of 00_intro files
Mar 18 13:12:05 <pmdboi> completely unrelated... would someone be willing to help with a fairly mundane problem?
Mar 18 13:12:09 --> mold (~morbid_d@bzq-82-80-216-40.red.bezeqint.net) has joined #dataflow
Mar 18 13:12:14 <_hc> I think if we are going to reorg this, we should also use it as a time to introduce something like doxygen
Mar 18 13:12:14 <Miller> sure, all we would need is a search tool, and perhaps a stronger tradition of using keywords wisely in descriptions.
Mar 18 13:12:33 <dpro> I also like the reference.txt idea but only rarely found it in larger collections
Mar 18 13:12:45 <bbogart> In pixelTANGO docs, I have a standard header with extra info, class of object, what it does etc..
Mar 18 13:12:56 <IOhannes> dpro: that's the same as 00_intro (?)
Mar 18 13:13:29 <Miller> I think if the search tool existed everyone would quickly decide to make an "intro" file ofr their
Mar 18 13:13:32 <_hc> if we have consistent use of a doc framework like doxygen, we could generate all of the above (00_intro, reference.txt, hierarchy. etc. etc. )
Mar 18 13:13:44 <IOhannes> metoo !
Mar 18 13:13:50 <Miller> ... libs. Problem I now see is what about individual files?
Mar 18 13:14:02 <IOhannes> which problem ?
Mar 18 13:14:09 <IOhannes> i mean, what is different
Mar 18 13:14:17 <IOhannes> apart from the amount of overhead
Mar 18 13:14:40 <Miller> Well, id someone put another one-off (an allpass filter, e.g.) in extra/, she's have to edit the "00_intro" file there.
Mar 18 13:15:17 <IOhannes> not with an automated search-mechanism that parses some files
Mar 18 13:15:21 <dpro> miller: doesn't sound too practical
Mar 18 13:15:25 <IOhannes> e.g. with a standard extension
Mar 18 13:15:30 <bbogart> What if we generate the _intro files from the help files in a directory?
Mar 18 13:15:45 <IOhannes> the problem is about parsing pd-files...
Mar 18 13:15:47 <dpro> maybe make install should cat myreference.txt >> 00_intro ?
Mar 18 13:16:07 <dpro> but I think a textfile is ok for starts
Mar 18 13:16:12 <IOhannes> and get thousands of duplicates
Mar 18 13:16:15 <Miller> So help windows could have a specially tagged comment line that gets thrown in the intro file.
Mar 18 13:16:16 <bbogart> This is a crazy idea, but some kind of structured text for PD documentation that can be used to generate PD patches would be nice. ;)
Mar 18 13:16:35 <minDfrqnc> dyn~ ?
Mar 18 13:16:37 * IOhannes is back at trying to think xml
Mar 18 13:16:40 --> tigital (~tigital@pool18.dial5-clec.noc.win.net) has joined #dataflow
Mar 18 13:16:43 <IOhannes> hi jamie
Mar 18 13:16:53 <bbogart> hey Jamie!
Mar 18 13:16:55 <tigital> hey IO
Mar 18 13:17:04 <_hc> why would we devise our own documentation system when there are many that exist already?
Mar 18 13:17:09 <bbogart> I think a special tag for PD help files is a great solution
Mar 18 13:17:11 <tigital> ok: hi everybody!
Mar 18 13:17:21 <IOhannes> i can think of something like a patch-property "help"
Mar 18 13:17:21 <_hc> I don't think our problem is totally unique
Mar 18 13:17:28 <IOhannes> obviously not
Mar 18 13:17:40 <IOhannes> but pd-patches are hard to extract info from
Mar 18 13:17:52 <Miller> I don't know doxygen, but could it be configured to make indices from Pd help files?
Mar 18 13:17:56 <IOhannes> if there is no real "special tag"
Mar 18 13:18:13 <_hc> doxygen works by parsing comments in C headers and source files
Mar 18 13:18:14 <bbogart> I don't think extracting a comment starting with "help-tag" or something would be very difficult?
Mar 18 13:18:31 <IOhannes> right, we wouldn't even need doxygen for that
Mar 18 13:18:34 <_hc> so no extra files would be needed
Mar 18 13:18:40 <IOhannes> but there are platforms that don't have sed
Mar 18 13:18:59 <IOhannes> or grep
Mar 18 13:19:01 <bbogart> a tcl script to do it should be easy.
Mar 18 13:19:12 <_hc> IO: cygwin is easy enough to install
Mar 18 13:19:16 <Miller> well, it's worse than 'sed' - I don't know a platform-independent way to recurse into directories.
Mar 18 13:19:18 <_hc> then we'd have a common platform
Mar 18 13:19:21 <IOhannes> or write an external ;-)
Mar 18 13:19:34 <bbogart> tcl will do it.. [file isdirectory]
Mar 18 13:19:37 <IOhannes> _hc: i don't think that cygwin is the way to go here
Mar 18 13:19:45 <dpro> _hc: but we wouldn'T like to add a cygwin dependency for the less fortunate would we ?
Mar 18 13:19:50 <bbogart> I put something in LML to decent directories...
Mar 18 13:20:03 <_hc> there are other sed and grep alternatives for windows
Mar 18 13:20:08 <number> man
Mar 18 13:20:15 <number> pd just had to crash during save
Mar 18 13:20:16 <dpro> IOhannes: we could use toxy, or pyext ;)
Mar 18 13:20:19 <number> not directly after
Mar 18 13:20:20 <number> D:
Mar 18 13:20:21 <_hc> sed for windows: http://gnuwin32.sourceforge.net/packages/sed.htm
Mar 18 13:20:27 <bbogart> Are we in agreement that the tagged comment approach is a good start?
Mar 18 13:20:43 <IOhannes> i only wish for as few dependencies as possible
Mar 18 13:20:45 <IOhannes> bbogart: yes
Mar 18 13:20:47 <dpro> ben: yup I'm in
Mar 18 13:20:49 <matju> Miller: i would like a way to map filename suffixes to hooks so that .py, .rb, .scm files can be put in the extra/ directory and that they could be recognized as regular externals/libraries
Mar 18 13:21:04 <matju> Miller: [prepend Dear Santa Claus...]
Mar 18 13:21:06 <bbogart> matju: ooooooo
Mar 18 13:21:10 <_hc> grep for windows: http://gnuwin32.sourceforge.net/packages/grep.htm
Mar 18 13:21:17 <_hc> there is also MinGW
Mar 18 13:21:31 <IOhannes> _hc: there is also linux, which you can install on any pc
Mar 18 13:21:35 <bbogart> regexp in tcl should be fine?!!?! or are we now trying to get away from using tcl in case the toolkit changes??
Mar 18 13:21:49 <mamalala> IOhannes: haha, good point ! ;)
Mar 18 13:21:55 <_hc> IO: I agree, less dependencies, but not to the extreme
Mar 18 13:22:12 <IOhannes> ben: i think that the help-browser can be made entirely in the toolkit
Mar 18 13:22:21 <IOhannes> i think matju has done it like that
Mar 18 13:22:25 <carmen> eliminating the dependency on 32bit arch would be great too... http://replic.net/~ix/pd/table64.png :)
Mar 18 13:22:28 <Miller> well, if the toolkit changes, it won't be the end of the world having to rewrite help indexing.
Mar 18 13:22:34 <_hc> IO: my point is that we shouldn't avoid UNIX standard tools just because they aren't included with Windows
Mar 18 13:22:47 <_hc> esp. when they are easy to install on WIndows
Mar 18 13:23:08 <matju> IOhannes: it's available in the latest devel_0_37, but in the Help menu instead of the File menu as it is in impd_0_37
Mar 18 13:23:09 <IOhannes> carmen: looks like it's spring
Mar 18 13:23:11 <_hc> and they are standard on _every_ other platform Pd runs on
Mar 18 13:23:18 <Miller> hc: sure, but a help facility is the netural place to include instructions for installing stuff. So shouldn't depend on anything.
Mar 18 13:23:22 <dpro> _hc: but then they should go directly into the win32 package
Mar 18 13:23:37 <dpro> miller: right!!!
Mar 18 13:24:07 <_hc> yes, help shouldn't depend on anything, but generating help can have dependencies
Mar 18 13:24:15 <IOhannes> and tcl is there already (for now)
Mar 18 13:24:22 <_hc> maybe I missed something, were you talking about using sed on the user's machine/
Mar 18 13:24:25 <_hc> ?
Mar 18 13:24:42 <IOhannes> _hc: yes generating the docs "online"
Mar 18 13:24:52 <_hc> ah... sorry
Mar 18 13:25:07 <IOhannes> otherwise it would be trivial...sorry
Mar 18 13:25:21 <matju> bbogart: i don't think the toolkit will change in the next few years. i say let's take advantage of the presence of tcl/tk when it makes sense
Mar 18 13:25:31 <tigital> I'm with ben, in that it can just be done with tcl/tk
Mar 18 13:25:32 <bbogart> It would be ideal if the doc system would work other places than the packages, if the users install some external separetly the index should be updated.
Mar 18 13:25:37 <Miller> yep.. the trick is, the user should be able to drop new stuff in and Pd find it for "help".
Mar 18 13:25:52 <IOhannes> exactement
Mar 18 13:25:59 <bbogart> woo hoo!
Mar 18 13:26:14 <matju> Miller: i thought that was what the "-help.pd" suffix was meant to be?...
Mar 18 13:26:36 <IOhannes> matju: the problem is with finding objects you don't know by name
Mar 18 13:26:42 <bbogart> ok, so do all the tags from the PD help files end up in some kind of index 00_intro?
Mar 18 13:26:46 <Miller> matju: yes, but we seem to need indexing and at least a simple hierarchy.
Mar 18 13:26:58 <bbogart> hence the functional organization of the doc menu.
Mar 18 13:27:18 <Miller> ben: I think the first time you hit "help index" (or something) it should build it in memory.
Mar 18 13:27:42 <IOhannes> why not generate it on startup ?
Mar 18 13:27:47 <IOhannes> (not that i would care)
Mar 18 13:27:58 <_hc> yeah, that's what happens now
Mar 18 13:28:08 <IOhannes> but might be better than having the re-indexing engine start-up whilst patching with a big PA
Mar 18 13:28:15 <IOhannes> _hc: ?
Mar 18 13:28:27 <matju> IOhannes: how is it a problem?... which other keys would you index the files with ?
Mar 18 13:28:30 <_hc> IO: the doc menu is generated on startup
Mar 18 13:28:45 <bbogart> Since we can't load externals without restarting PD the indexing need not be a user-choice.
Mar 18 13:28:50 <IOhannes> oh, the "new" one with the funny sub-directories...
Mar 18 13:28:59 <IOhannes> bbogart: who told you that ?
Mar 18 13:29:22 <IOhannes> matju: i was thinking about drop-outs and alike
Mar 18 13:29:35 <-- _hc has quit ()
Mar 18 13:29:44 <bbogart> oops, am I getting confused about libs again?
Mar 18 13:30:03 <matju> IOhannes: what do you mean ?
Mar 18 13:30:22 --> _hc (~purecanes@user-0cdf4hn.cable.mindspring.com) has joined #dataflow
Mar 18 13:30:25 <bbogart> Is it possible to functionally organize all externals into meaningful groups that all developers can be happy with?
Mar 18 13:30:34 <Miller> I think the question was, what if someone asks for help during a concert?
Mar 18 13:30:41 <IOhannes> matju: re-indexing during performance (because i like to do patching during performance and i might even....
Mar 18 13:30:45 <IOhannes> miller: thats what i mean
Mar 18 13:30:46 <-- dto has quit (Remote closed the connection)
Mar 18 13:31:02 <IOhannes> bbogart: i don't think so (personally)
Mar 18 13:31:22 <bbogart> What about abstractions? It would be nice if they were totally seamless as objects, add a new abstraction and it also gets indexed, it also has a standard help file...
Mar 18 13:31:43 <_hc> I second that
Mar 18 13:31:56 <matju> Miller: well, if it's the client doing it, as we are saying, then there wouldn't be a problem with help files during performances.
Mar 18 13:32:02 <tigital> most abstractions don't seem to have help files, atm
Mar 18 13:32:04 <bbogart> IO: I think for the new user's sake we should make it happen! I think its possible, though probably difficult.
Mar 18 13:32:23 <bbogart> abstractions SHOULD have help-files. :)
Mar 18 13:32:43 <Miller> So perhaps the thing to do is re-build the hierarchy everytime the user hits 'help'.
Mar 18 13:32:43 <bbogart> otherwise they will not get indexed, and then no one will use them because they don;t know they exist. ;)
Mar 18 13:33:01 <bbogart> if this does not bog down the menu generation much that could work.
Mar 18 13:33:06 <_hc> miller: that will make hitting "help" really slow
Mar 18 13:33:24 <IOhannes> or doing it incremental
Mar 18 13:33:29 <minDfrqnc> slow is okay if it becomes more useful
Mar 18 13:33:30 <IOhannes> (however this could be done)
Mar 18 13:33:44 <bbogart> I think is the index is built before a patch is loaded then its not a problem never will be during a performance because there is no patch loaded.. if we use -open I dunno...
Mar 18 13:33:58 <IOhannes> bbogart: not true for me
Mar 18 13:34:12 <IOhannes> i _do_ live patching, and i guess others too
Mar 18 13:34:13 <Miller> Sure, but if the average number of times the user hits 'help' is less than one per Pd run, you would do better to wait to do the indexing.
Mar 18 13:34:45 <IOhannes> but on startup no-one might notice
Mar 18 13:34:51 <Miller> I sure do!
Mar 18 13:34:52 <_hc> why not just index on startup, and make a menu item to reindex manually
Mar 18 13:34:55 <IOhannes> (if its not done in java)
Mar 18 13:35:02 <bbogart> Miller: I have to disagree, I see students jumping on help often, and they'll do it more if it becomes this useful!
Mar 18 13:35:04 <tigital> _hc: yes
Mar 18 13:35:11 <bbogart> HC: I agree.
Mar 18 13:35:20 <IOhannes> _hc: sounds good to me too
Mar 18 13:35:39 <Miller> Anyhow, I think there are two levels of indexing to try. First, making the menus themselves, and second (and longer), building an index.
Mar 18 13:36:03 <_hc> yeah, I built-in pdb would be really sweet
Mar 18 13:36:56 <minDfrqnc> and have it be updated from a remote repository manually
Mar 18 13:37:15 <_hc> no, from the files on the users machine
Mar 18 13:37:24 <minDfrqnc> ah ok
Mar 18 13:37:30 <Miller> Making the menus could be on-demand, even fine grained: don't bother to make the FFT object menu until it has to be posted.
Mar 18 13:37:56 <IOhannes> miller: is the task of menu-generation so demanding (once you have the index) ?
Mar 18 13:38:04 <Miller> Then, when you hit "help index", you get a dialog for keywords, and then once
Mar 18 13:38:22 <Miller> that's selected, you actually look inside all the help windows for the keyword(s).
Mar 18 13:38:22 --> proswell (~jmisra@inpuj.com) has joined #dataflow
Mar 18 13:38:23 <matju> _hc: i agree that it should be once at startup and then manually; but also, in impd/devel i'm rebuilding the index from scratch and even if i have a truckload of externals it's still fast to rebuild upon each use.
Mar 18 13:38:37 <_hc> but slow menus suck
Mar 18 13:38:46 <_hc> and it doesn't take much to make UI elements feel slow
Mar 18 13:38:55 <matju> _hc: have you tried it?
Mar 18 13:39:03 <_hc> slow menus?
Mar 18 13:39:05 <Miller> I think running regexp on 1000 help files or so shouldn't take more than a second.
Mar 18 13:39:15 <_hc> 0.5 sec is a slow response
Mar 18 13:39:23 <Miller> ... and this is only _after_ you ask to search.
Mar 18 13:39:37 <_hc> my poor old 800 MHz laptop would not reindex help files faster than that
Mar 18 13:39:38 <bbogart> Miller: the array searching stuff in tcl is certainly faster than a normal loop too.
Mar 18 13:39:40 <matju> _hc: have you tried the class browser? does it feel slow to you?
Mar 18 13:40:00 <_hc> I have not tried it
Mar 18 13:40:07 <_hc> got a MacOS X binary I can try?
Mar 18 13:40:27 <matju> _hc: do you have osx binaries of devel_0_37 ?
Mar 18 13:40:33 <_hc> no
Mar 18 13:40:34 <tigital> _hc: i'll make one for ya this weekend
Mar 18 13:41:08 <_hc> tigital: post it somewhere, I am sure more people would be interested
Mar 18 13:41:15 <bbogart> tigital: I'd like to play with it too!
Mar 18 13:41:21 --> normand (~normand@66.11.191.17) has joined #dataflow
Mar 18 13:41:25 <tigital> o-tay
Mar 18 13:41:40 <matju> _hc: i recall gerard published binaries of impd_0_37_A2 a year ago; maybe you could try those if they're still available.
Mar 18 13:41:55 <bbogart> so I think we have a handle on this. How does the current discussion relate to the structure of the "doc" folder, and the idea of funcional organization?
Mar 18 13:42:25 <_hc> bbogart: dynamic content making the UI slow
Mar 18 13:42:42 <Miller> I think the "help" files (doc/5.reference) should just be searched along with "extra".
Mar 18 13:43:07 <Miller> The other "doc" stuff, I don't know.
Mar 18 13:43:33 <IOhannes> so: doc/5.reference is for internal help, and extra/ for external
Mar 18 13:43:39 <Miller> (one thing coming soon: 4.fft will become chapter 9 in "3".
Mar 18 13:43:44 <bbogart> I find the naming "5.reference" quite anoying. "Reference" or "Object-Reference" is more friendly.
Mar 18 13:44:04 <_hc> the leading numbers control the order
Mar 18 13:44:07 <_hc> its handy like that
Mar 18 13:44:12 <bbogart> Miller: did everyone see my stab at doc/ from today?
Mar 18 13:44:13 <Miller> Yep, I don't know any more why I thought that had to be numbered.
Mar 18 13:44:35 <Miller> I didn't .... is it up somewhere?
Mar 18 13:44:36 <IOhannes> yes, there is no use in having the reference-files on the 5th place or an the 2nd
Mar 18 13:44:44 <bbogart> Indeed, but I think we're trying to get people to navigate through the menu for help, not the directory structure istelf (in which case it does not matter what the names are much)
Mar 18 13:44:53 <Miller> I _did_ what the HTML to show up first in the browser.
Mar 18 13:45:01 <Miller> Hence, "0.intro".
Mar 18 13:45:02 <_hc> I think that the order of the doc/ dir could be used well
Mar 18 13:45:08 <_hc> like an order to proceed for beginners
Mar 18 13:45:15 <IOhannes> yes this is all perfect.
Mar 18 13:45:23 <minDfrqnc> miller, wasn't if to go along with the chapters in your book?
Mar 18 13:45:26 <matju> btw here's a screenshot of the class browser: http://artengine.ca/matju/impd/gallery/class_list_3.gif
Mar 18 13:45:36 <Miller> Yep, chapter 9 is on FFTs.
Mar 18 13:45:41 <bbogart> HC: I think this makes sence, which I would put "externs" at the very end and "reference" just after examples? (examples is another issue... )
Mar 18 13:45:41 <IOhannes> but the 5.reference is not within this ordering scheme....
Mar 18 13:45:46 <minDfrqnc> i meant the numbereings
Mar 18 13:45:51 <minDfrqnc> okayt
Mar 18 13:45:59 * IOhannes types to slow
Mar 18 13:46:41 <Miller> IO: right. does it even belong in 'doc' then?
Mar 18 13:47:02 <matju> _hc: i demoed the class browser at the pd convention. do you recall it being slow?
Mar 18 13:47:03 <bbogart> matju: class-browser is very cute, but a little too techy, needs to look more like documentation and less like a C++ class browser
Mar 18 13:47:16 <IOhannes> miller: you mean: make a new directory "help" outside of doc ?
Mar 18 13:47:52 <Miller> I think I mean, "help" should browse the HTML doc and examples; reference doesn't logically belong there.
Mar 18 13:48:07 <bbogart> I'm seeing three different kinds of "documentation". there are the html docs, there are the "help" files which demo one object in context, and then there are examples that describe concepts using multiple objects.
Mar 18 13:48:10 <IOhannes> in gem we have directories "help" "doc" "manual" (and upcoming: "reference" "faq"....;-))
Mar 18 13:48:15 <minDfrqnc> maybe because the numbers help it show up in order in a directory listing ?
Mar 18 13:48:19 <bbogart> Miller:yes.
Mar 18 13:48:25 <IOhannes> miller: all right, but where to put it then ?
Mar 18 13:48:34 <IOhannes> it's not _that_ bad place
Mar 18 13:48:38 <minDfrqnc> i always number my file names so i see them in the order i want them to be in a directory listening
Mar 18 13:48:44 <bbogart> doc/manual doc/reference doc/examples
Mar 18 13:48:53 <matju> bbogart: how does my class browser look too much like a C++ class browser, as opposed to another kind of class browser ?
Mar 18 13:49:02 <Miller> Gotta think about that...
Mar 18 13:49:17 <bbogart> matju: The information given is not of much use to a biginner
Mar 18 13:49:32 <bbogart> "what does it do"
Mar 18 13:49:33 <_hc> miller: I think the object reference works fine with the rest of the docs in one place
Mar 18 13:49:36 <bbogart> "how do I use it"
Mar 18 13:49:43 <bbogart> "open the reference patch"
Mar 18 13:50:04 <IOhannes> bbogart: this brings us back to the tagging issue
Mar 18 13:50:04 <_hc> miller: sometimes people might want to browse the reference
Mar 18 13:50:15 <tigital> bbogart: but that info can be put in: the structure/design is the important thing right now
Mar 18 13:50:24 <matju> bbogart: if you mean the stuff on the right-hand panel, i did put this as a proof of concept, but there is currently no way for externals/abstractions to register more useful info.
Mar 18 13:50:32 <Miller> yikes, thought I was the only one who actually browsed reference...
Mar 18 13:50:40 <IOhannes> ;-)
Mar 18 13:50:44 <bbogart> tigital: oh I agree, perhaps I was just stating the obvious.
Mar 18 13:50:45 <matju> bbogart: besides, if you want to know what an object does, why don't you click the Help button on the left ?
Mar 18 13:51:27 <bbogart> When teaching Gem I tell my students to open up the 5.reference folder to get a sense of available functionality, though its not organized by function...
Mar 18 13:51:27 <matju> bbogart: the class browser is there mostly for searching. However it's true that the name-completion feature makes it semi-useless.
Mar 18 13:51:37 <matju> bbogart: http://artengine.ca/matju/impd/gallery/completions.gif
Mar 18 13:52:08 <IOhannes> auto-completion kept me from using max
Mar 18 13:52:09 <bbogart> matju: ah, that looks familar. :)
Mar 18 13:52:30 <bbogart> in vvvv the auto-completion Includes short descriptions of each object!!!
Mar 18 13:52:54 <matju> IOhannes: in IMPD it's not auto, you have to press Tab like in bash, and then you still have to type it yourself
Mar 18 13:53:01 <IOhannes> so if this ever going to happen: please allow me to disable it
Mar 18 13:53:05 <Miller> I have a personal distaste for stuff that 'pops up'... don't know if other people share that or not.
Mar 18 13:53:06 <IOhannes> matju: ok, that sounds great
Mar 18 13:53:17 <IOhannes> miller: at least i do
Mar 18 13:53:33 <_hc> I don't like popping up things, but many people love them
Mar 18 13:53:49 <_hc> Max/MSP users, for example
Mar 18 13:53:52 <Miller> On the other hand, stuff that appears on margins can be really great.
Mar 18 13:54:15 <Miller> hc: and Windoes users love that little puppy too.
Mar 18 13:54:16 * IOhannes wants to talk to krzYszcz later (just don't allow me to forget it)
Mar 18 13:54:16 <_hc> yeah, its much more lightweight
Mar 18 13:54:50 <IOhannes> winwoes ?
Mar 18 13:55:03 <bbogart> Any ideas on grouping objects by functionality? (based on my crack at it posted today)
Mar 18 13:55:35 <minDfrqnc> do you guys have a set agenda to talk about i could see?
Mar 18 13:55:47 <tigital> I seem to remember matju at pd-conv saying the impd features will always be able to be turned on/off
Mar 18 13:55:50 <IOhannes> bbogart: what did you post where ?
Mar 18 13:55:56 <tigital> "use what you want"
Mar 18 13:56:20 <IOhannes> load these features as an external ;-=
Mar 18 13:56:48 <Miller> minDfrqnc... the agenda usually appears _after_ the meeting :)
Mar 18 13:57:04 <minDfrqnc> ok :)
Mar 18 13:57:06 <_hc> did the transcript from thje last mtg get posted anywher?
Mar 18 13:57:07 <minDfrqnc> i'll sit still then
Mar 18 13:57:37 <IOhannes> hc: yes, it is at puredata.info
Mar 18 13:57:56 <Miller> IO: thanks for putting that up - I dn't know how to save these things.
Mar 18 13:58:15 <IOhannes> http://puredata.info/community/IRC/dev0501/
Mar 18 13:58:24 <IOhannes> miller: me neither, but matju does
Mar 18 13:58:35 <bbogart> IO: functionality grouping of objects: Ah its not in the achive yet...
Mar 18 13:59:30 <bbogart> IO: I don't want to paste it here.
Mar 18 13:59:30 <IOhannes> ben: i do not remember seeing it on any list
Mar 18 13:59:52 <bbogart> maybe I sent it to HC only.. ?
Mar 18 14:00:24 * IOhannes is receiving malware...
Mar 18 14:00:40 * IOhannes doesn't know how to accept it
Mar 18 14:00:45 <matju> Miller: http://artengine.ca/matju/dataflow-20050226-meeting.irc
Mar 18 14:00:58 <Miller> Would anyone be interested in continuing discussion of getting IMPD-style raster slicing support into Pd? (this started last time as Tim's topic on vectorizing)
Mar 18 14:01:00 <matju> Miller: menu Window -> Save Text...
Mar 18 14:01:15 <bbogart> oops, unsent mail...
Mar 18 14:01:19 <bbogart> I sent it now.
Mar 18 14:01:20 <Miller> matju: thanks. There it is...
Mar 18 14:01:21 <_hc> IO: his post was on a different thread...
Mar 18 14:01:32 <matju> Miller: IMPD does not support raster slicing.
Mar 18 14:01:38 <matju> Miller: (whatever that is)
Mar 18 14:01:38 <IOhannes> the one at puredata.org is just a copy from artengine
Mar 18 14:01:44 <_hc> IO: I mean unrelated thread title
Mar 18 14:01:54 <Miller> Well, I don't know a name for it, will describe.
Mar 18 14:02:04 <_hc> bbogart: I am pretty sure it went to the list, it was in my list folder
Mar 18 14:02:07 <IOhannes> _hc: i thought so
Mar 18 14:02:20 <Miller> Idea is you take a vector much too big to fit in cache, and slice it up, running tilde
Mar 18 14:02:38 <Miller> objects on (for instance) single rows of a plane in an image.
Mar 18 14:02:54 <bbogart> hehe, sounds very gridflow Miller!
Mar 18 14:02:55 <Miller> The trick is, if you ever want to rearrange the image (rotate it, say) you might
Mar 18 14:02:57 <IOhannes> _hc: but my mail-client refuses to search
Mar 18 14:03:12 <Miller> have to 'demand' more input before your corresponding output is possible to calculate.
Mar 18 14:03:14 <_hc> IO: let's see...
Mar 18 14:03:54 <IOhannes> ben: i guess it is the one that just arrived
Mar 18 14:03:57 <Miller> I'm under the impression IMPD does that... Or maybe I'm calling it by the wrong name; I mean the APL implementation
Mar 18 14:04:07 <Miller> you were using for image processing at the Convention.
Mar 18 14:04:53 <tigital> miller: pretty sure that's gridflow
Mar 18 14:04:53 <Miller> Oh, I think Gridflow is what I meant.
Mar 18 14:05:01 <bbogart> I have to go, but I've made a few notes on our discussion of help. I'm sending it to the pd-dev list now
Mar 18 14:05:19 <tigital> bbogart: ciao!
Mar 18 14:05:20 <bbogart> seeya all later!
Mar 18 14:05:29 <IOhannes> ben: bye
Mar 18 14:05:30 <Miller> bye and thanks Ben.
Mar 18 14:05:34 <_hc> bbogart: yeay documentation! byte..
Mar 18 14:05:46 <_hc> bbogart: bye
Mar 18 14:05:56 <bbogart> bye
Mar 18 14:06:07 <-- bbogart has quit ("Leaving")
Mar 18 14:06:10 * IOhannes remembers that he wanted to mention the nyquist bin
Mar 18 14:06:12 <matju> Miller: images in GF are usually not planar, but you can transform a (240,320,3) in a (3,240,320) by using [#transpose]...
Mar 18 14:07:01 <Miller> Anyhow, I'm wondering if some changes to "block~" couldn't make some of this possible.
Mar 18 14:07:04 <matju> Miller: do you want to discuss the ways of slicing the data into gf-packets, or another aspect?
Mar 18 14:07:36 <Miller> I'm thinking about (well, what am I thinking about really?)
Mar 18 14:07:42 <IOhannes> or is it about virtually any blocksizes which could fit more for other things like images
Mar 18 14:07:55 <IOhannes> (whatever this means)
Mar 18 14:08:06 <Miller> I think it's more about changing the semantics of bocking.
Mar 18 14:08:13 <Miller> (blocking, sorry).
Mar 18 14:08:31 <IOhannes> that is ?
Mar 18 14:08:46 <IOhannes> (i mean, as an example)
Mar 18 14:08:54 <matju> IOhannes: blocks are too... blocky. so miller wants to make them rounder.
Mar 18 14:08:55 <Miller> For example, if you have a block that is in fact a line of a raster, its sample
Mar 18 14:09:09 <Miller> rate might be 30, but there might be more than 30 of them per second.
Mar 18 14:10:23 <Miller> So a line of a raster might want to know that it is (1) a single point in time; (2) a single point of RGBA; (3) a single point vertically; but (4) reaching from 0 to 525 horizontally.
Mar 18 14:10:57 <IOhannes> yay; seems to be gridflow
Mar 18 14:11:01 <Miller> That way, objects like "delay~", "tabwrite~", etc. might have more control over what
Mar 18 14:11:03 <matju> Miller: so are you thinking about adding grids directly to pd ? or just grid-shaped signals ?
Mar 18 14:11:08 <Miller> they do.
Mar 18 14:11:41 <Miller> I don't know. My instinct is to try first to see if the tilde business can be
Mar 18 14:11:53 <Miller> extended to allow for a good subset of grid functionality.
Mar 18 14:12:26 <matju> Miller: i'd say, first add support for multiple channels, but leave open the possible to add more channel-like dimensions later on
Mar 18 14:13:07 <matju> change "possible" to "possibility"...
Mar 18 14:13:26 <IOhannes> that is a good thing to start with (but i don't see (yet) how to make it work without rewriting each external~
Mar 18 14:14:13 <Miller> Sure, I think that's easy to do, but the hard part is thinking about allowing some kind of reordering so that objects can index into their inputs and that would possibly mean 'go back and calculate more input'.
Mar 18 14:14:52 <Miller> IOhannes: you could make some objects multi-dimensional-capable, leave others as is.
Mar 18 14:14:54 <matju> IOhannes: i see a few possibilities. Like, externals not supporting multiple-channels would be automatically duplicated so as to be able to process each channel independently
Mar 18 14:15:09 <IOhannes> well, simple enuff
Mar 18 14:15:31 <IOhannes> but the fun would start with automatic ability
Mar 18 14:15:35 <Miller> Objects that have no state could just operate on anything at all, with no problems.
Mar 18 14:16:15 <matju> Miller: yeah, cool, but how do you determine whether an object has a state or not?
Mar 18 14:16:59 <Miller> Well, the ones that do (lop~ fr instance) would just low-pass along the dimension which is the order of computation.
Mar 18 14:17:59 <IOhannes> i am just trying to remember some discussions i had with tm on this topic
Mar 18 14:19:04 * IOhannes thinketh
Mar 18 14:19:18 * IOhannes stops thinking
Mar 18 14:19:30 <Miller> One thing we'd need is a way to get into and out of PdP, Gridflow, and Gem efficiently.
Mar 18 14:20:13 <IOhannes> well, we would even need better bridges between these themselves
Mar 18 14:20:35 <IOhannes> (but if pd would handle it _really_ efficient this might be easy)
Mar 18 14:20:44 <Miller> Or indeed, use the tilde world as the bridge...
Mar 18 14:21:06 <IOhannes> yes, that's what i meant (and replace "might" with "will")
Mar 18 14:21:16 <matju> Miller: first, is it possible to adapt arrays to do this ?
Mar 18 14:21:25 <Miller> one thing I'm worried about is that we'd need conversion routines between pixel formats.
Mar 18 14:21:35 <IOhannes> matju: floating point arrays ?
Mar 18 14:21:55 <dpro> miller: you mean colorspace ?
Mar 18 14:21:55 <matju> IOhannes: arrays. (which currently support floats and datastructs)
Mar 18 14:22:00 <IOhannes> miller: true, but what could be a possible solution
Mar 18 14:22:03 <Miller> I'm getting worried about one aspect of arrays... in 64-bit land you need 64 bits to hold each number
Mar 18 14:22:26 <mamalala> a way would be to pack streams together with some info for each packet. so the receiving object can see what it is and decide on that ....
Mar 18 14:22:29 <Miller> (because each iten is actually an 'atom').
Mar 18 14:22:30 <matju> Miller: there's at least one format that GF and GEM have in common
Mar 18 14:22:31 <IOhannes> dpro: colorspaces _and_ types (e.g. pdp uses short, while Gem uses uchar)
Mar 18 14:22:39 <matju> Miller: and there's at least one format that GF and PDP have in common
Mar 18 14:23:19 <Miller> I just finished unifying "g_array"s and data arrays, and then realized that in the
Mar 18 14:23:19 <dpro> mamalala: packet forth already uses some sort of mime like header
Mar 18 14:23:26 <IOhannes> and conversion routines are needed to import/export data from other sources (e.g. movies) too
Mar 18 14:23:37 <Miller> end we need storage objects that hold data more compactly!
Mar 18 14:23:45 <dpro> iohannes: right and up to now you all cooked your own ;)
Mar 18 14:23:56 <matju> IOhannes: and gridflow uses uchar, short, int32, int64, float32, and float64.
Mar 18 14:24:15 <IOhannes> matju: i didn't dare to think of that
Mar 18 14:24:19 <dpro> matju: but already provides routines to convert between types
Mar 18 14:24:34 <matju> Miller: i'd also like arrays of uint8, int16, int32, which are incidentally the three most used types in GF
Mar 18 14:25:02 <IOhannes> dpro: mea culpa (but it was easier that go and find a lib that does it;-))
Mar 18 14:25:42 <IOhannes> matju: me too; that is why i have done this iem16 (16bit arrays/delays) but apparently they cannot be mixed with other arrays
Mar 18 14:25:59 <IOhannes> "other":="normal"
Mar 18 14:26:06 <matju> dpro: [#cast] can cast to any of the 6 types; plus there are operators for converting from YUV to RGB and such, which can be adapted to other variants, because they are abstractions around [#inner] the friendly matrixproduct operator
Mar 18 14:27:08 <matju> Miller: _and_ i'd like arrays of _atoms_ (as i said on the mailinglist)
Mar 18 14:27:28 <-- wip2 has quit (Read error: 104 (Connection reset by peer))
Mar 18 14:27:29 <Miller> you mean, typed atoms?
Mar 18 14:27:51 <IOhannes> compactness be gone
Mar 18 14:27:52 <dpro> santa: oh yes I want argc inside abstractions (while we are at it)
Mar 18 14:28:09 <IOhannes> dpro: that is a very good point: argc _and_ argv
Mar 18 14:28:38 <Miller> hmm... maybe data-buffering and first-class 'data'-style arrays just have to be treated differently. That would be a drag...
Mar 18 14:29:46 <matju> Miller: what do you mean, typed atoms?
Mar 18 14:29:59 <IOhannes> santa: and enlargen the symbol-hash (if it hasn't been done already)
Mar 18 14:30:09 <Miller> type + datum, total of 2 (machine words).
Mar 18 14:30:13 <matju> Miller: i mean arrays of atoms. i mean being able to mix floats/symbols/pointers in the same array.
Mar 18 14:30:26 <matju> Miller: yes, that is it.
Mar 18 14:30:29 <-- chikun has quit (Read error: 110 (Connection timed out))
Mar 18 14:30:32 <Miller> yep, that means splling 32 or 64 more bits for a type.
Mar 18 14:30:41 <matju> Miller: and then what?
Mar 18 14:30:52 <Miller> then everything slooows down.
Mar 18 14:30:57 <mamalala> huh ?
Mar 18 14:31:10 <matju> Miller: i don't mean those _replacing_ existing arrays.
Mar 18 14:32:10 <Miller> Hmm, so it could just be extending the notion of array so that the elements could be of more types than just 'pure data' structures.
Mar 18 14:32:34 <matju> Miller: yeah, or even, extend templates so that they can have something else than floats in them.
Mar 18 14:33:31 --> wip2 (~wip@Kitchener-HSE-ppp3579831.sympatico.ca) has joined #dataflow
Mar 18 14:33:33 <Miller> yep, maybe that's not as hard as I imagined, now that I think about it.
Mar 18 14:34:34 <matju> Miller: and one of the types would be "atom", that is, something that could be a float or symbol or whichever, but is slower than deciding the type beforehand
Mar 18 14:35:11 <Miller> Since we're in C land, this means writing big switch statements everywhere... something I did in Max (remember 'integers'?) but then started to hate.
Mar 18 14:35:16 <IOhannes> ok i am getting tired by now...
Mar 18 14:35:25 <IOhannes> and still have some questions i wanted to mention
Mar 18 14:35:41 <IOhannes> so if no one objects:
Mar 18 14:35:45 <IOhannes> a) the nyquist bin
Mar 18 14:36:01 <matju> Miller: that's about where you start considering C++...
Mar 18 14:36:24 <matju> Miller: or at least, some sizeable system of macros.
Mar 18 14:36:43 * IOhannes starts coding pd++
Mar 18 14:36:47 <Miller> IO: Sure... it's easy, I don't want to do it for 0.38 since I finally got it mostly working. I've got some bugs still in 0.39 but will try to get it out soon and fix FFTs there.
Mar 18 14:37:22 <IOhannes> and will it just spill the Nth sample of the signal vector ?
Mar 18 14:37:39 --> aalex (~aalex@65.94.92.145) has joined #dataflow
Mar 18 14:37:55 <IOhannes> or - ugly enuff - spill the dummy 0th pin ?
Mar 18 14:37:57 <Miller> What does spilling Nth sample mean?
Mar 18 14:38:31 <IOhannes> right now, [rfft~] output exactly 64 samples (at a blocksize of 128)
Mar 18 14:38:40 <IOhannes> the nyquist would be the 65th sample
Mar 18 14:38:41 <Miller> (BTW - czero_rev is backwards in 0.38, beware.)
Mar 18 14:38:54 <IOhannes> so "Nth" was stupid
Mar 18 14:39:15 <IOhannes> but normally you can jsut skip half of the signal-vector when doing fft's
Mar 18 14:39:24 <IOhannes> this can be used for more efficiency
Mar 18 14:39:28 <Miller> Oh. But rfft~ puts out two 128-element vectors, so yes, there'd be 65 nonzero ones
Mar 18 14:39:35 <Miller> for the real part and 63 for the imaginary.
Mar 18 14:39:42 <IOhannes> right, thats ok
Mar 18 14:40:07 <IOhannes> i once made this "downsampling" that would skip the second half of the block
Mar 18 14:40:15 <IOhannes> to make it faster
Mar 18 14:40:22 <IOhannes> (to not do void calculations)
Mar 18 14:40:35 <Miller> Oh... I thought about that idea and got confused and gave up on it.
Mar 18 14:40:38 <IOhannes> this would loose 1 pin (but i don't really care)
Mar 18 14:41:02 <IOhannes> the missing nyquist is ok for most musical applications, but not for technical ones
Mar 18 14:41:19 <Miller> OK and technical stuff can just be inefficient.
Mar 18 14:41:29 <IOhannes> that's what i was thinking too
Mar 18 14:41:38 <IOhannes> and speaking of up/downsampling::
Mar 18 14:42:03 <IOhannes> do you still think that giving the resampling method as an argument to iolet~s is a bad idea ??
Mar 18 14:42:33 <IOhannes> (i remember you saying something like this once we were talking about tooltips)
Mar 18 14:42:37 <Miller> I think it's not strictly necessary... you can pull anything you want off without that.
Mar 18 14:42:46 <IOhannes> ?
Mar 18 14:43:19 <IOhannes> you mean the idea of having different resampling algorithms within _one_ subpatch is overhead ?
Mar 18 14:43:44 <Miller> no, I just mean you can make filters explicitly.
Mar 18 14:44:05 <Miller> only thing is, you need slightly wierd filters.
Mar 18 14:44:23 <IOhannes> i always thought this a bad idea, as you would have to adjust the parent-patch
Mar 18 14:44:39 <Miller> I don't think so.
Mar 18 14:44:50 <IOhannes> and i really loved the transpareny of the re-blocking thing
Mar 18 14:44:52 <dpro> guys, gotta go, there'll be more dev meetings, but my dear friend will only get 30 once ;)
Mar 18 14:45:09 <Miller> Sure, I turned 30 once too. Have fun.
Mar 18 14:45:16 <dpro> hehe
Mar 18 14:45:16 <dpro> cu
Mar 18 14:45:18 <IOhannes> dpro: ok, nice you have been here
Mar 18 14:45:20 <mamalala> Miller: are there any plans for a remote gui implementation in pd ? so that pd and its gui are seperated processes ?
Mar 18 14:45:21 <IOhannes> bye
Mar 18 14:45:28 <-- dpro has quit (""partytime"")
Mar 18 14:45:39 <IOhannes> mamalala: they are since i know pd
Mar 18 14:45:52 <-- aalex has quit (Remote closed the connection)
Mar 18 14:46:01 <mamalala> IOhannes: aha, and what about the state of the plans ? ;-)
Mar 18 14:46:23 <Miller> There's a nice GUI out for Pd, GripD, by Joe Sarlo.
Mar 18 14:46:34 <IOhannes> and toxy
Mar 18 14:46:48 --> aalex (~aalex@65.94.92.145) has joined #dataflow
Mar 18 14:46:51 <mamalala> Miller: no, i dont mean that, i mean to be able to use a alternative gui for patching etc.....
Mar 18 14:47:00 <Miller> Yep, and now that browser plug-in trick as well...
Mar 18 14:47:23 <IOhannes> ah speaking of toxy, krzyszcz, i have one question regarding [speedlimit]
Mar 18 14:47:44 <Miller> Oh... well, theoretically, you can do that, although it would be ugly because you'd
Mar 18 14:48:03 <Miller> have to parse Pd's GFX commands and handle them differently...
Mar 18 14:48:46 <mamalala> Miller: well, why not dropping them for that purpose, just passing object-id's, positions, sizes etc. around ?
Mar 18 14:49:03 <Miller> Matju has pulled off one way of making the connection more abstract (IMPD, right?)
Mar 18 14:49:11 <IOhannes> krz: is the behaviour with the 1st value to be speedlimited a bug or a feature ?
Mar 18 14:49:54 <Miller> IO: probably a feature... the first value passes through without delay.
Mar 18 14:50:04 <Miller> Max does it that way (I wrote that back in 1988...)
Mar 18 14:50:25 <IOhannes> no, i mean the 1st value to be speedlimited
Mar 18 14:50:38 <IOhannes> this is the second value (which arives faster than it should)
Mar 18 14:50:50 <IOhannes> and is passed through directly too
Mar 18 14:51:10 <IOhannes> *if* it after half of the speedlimit-time
Mar 18 14:51:11 <Miller> mamalala: this is also how Jmax operates, I think.
Mar 18 14:51:19 <mamalala> Miller: right ....
Mar 18 14:51:30 --> wip (~wip@Sherbrooke-HSE-ppp3612288.sympatico.ca) has joined #dataflow
Mar 18 14:51:46 <IOhannes> (at least thomas musil told me this today, as he was trying to find collisions between iemlib and cyclone)
Mar 18 14:52:03 <Miller> (I think this is one of the reasons Jmax got too heavy to lift, even for IRCAM).
Mar 18 14:52:04 <matju> Miller: IMPD replaces almost all sys_vgui()'s by sys_mgui()'s and pd_upload()'s
Mar 18 14:52:35 <matju> Miller: where sys_mgui() takes an object and a list of t_atoms, instead of flat text
Mar 18 14:52:52 <mamalala> hmm, i dont think so .... the separation of gui and kernel is nice, just using swing for the gui is a bad idea .....
Mar 18 14:53:16 <matju> Miller: and where pd_upload() uploads a new copy of a given object to the tcl/tk side (which should eventually be optimised so that it only sends diffs)
Mar 18 14:53:38 <IOhannes> speedlim: excample1:: t=1000; value0 arrives at t0 and appears immediately; value1 arrives at t0+200 and appears at t0+1000;
Mar 18 14:54:02 <IOhannes> speedlim: example2:: t=1000; value0 arrives at t0 and appears immediately; value1 arrives at t0+600 and appears at t0+600
Mar 18 14:54:07 <Miller> I'm still trying to decide just how structured the up-communication should be... too structured and things get heavy, not enough and they get stupid.
Mar 18 14:55:08 <Miller> (right now it's on the stupid side of the balance.)
Mar 18 14:56:15 <Miller> IO: the original speedlim was gurarnteed never to send two values within less than the specified time. This might have been changed since I got out of Max though.
Mar 18 14:56:42 <IOhannes> yes, this was our assumption too (and is the behaviour of iemlib ;-))
Mar 18 14:57:05 <-- normand has quit ("Leaving")
Mar 18 14:57:06 <IOhannes> so i wanted to ask krzyzszcz whether this is a feature (compatibility to max) or a bug
Mar 18 14:57:18 <matju> Miller: i think i'm on the right track and that it's just that i haven't implemented diffs because i simply never got to that point.
Mar 18 14:58:01 <Miller> Matju: there's also a delayed-update feature in 0.38, which puts the onus on the
Mar 18 14:58:09 <Miller> object instead of the interface.
Mar 18 14:58:39 <matju> Miller: what do you mean by "heavy to lift" ?
Mar 18 14:58:47 <minDfrqnc> hard to manage?
Mar 18 14:59:10 <Miller> Well they sank about 30 man-years into it and it never quite worked.
Mar 18 14:59:19 <-- wip has quit (Read error: 54 (Connection reset by peer))
Mar 18 14:59:22 --> wip (~wip@Kitchener-HSE-ppp3577943.sympatico.ca) has joined #dataflow
Mar 18 14:59:23 <-- wip2 has quit (Read error: 60 (Operation timed out))
Mar 18 14:59:29 <Miller> That's probably between 1.5 and 2 million USD.
Mar 18 14:59:30 --> normand (~normand@66.11.191.17) has joined #dataflow
Mar 18 14:59:54 <tigital> matju: you are on the right track...
Mar 18 15:00:04 <matju> Miller: yeah ok, but what's the cause of that waste? i lost you at some point
Mar 18 15:02:07 <carmen> some of these new linux synths with asynchronous-OSC GUI communication are itneresting..open up multiple GUI clients, and changing one updates the other..
Mar 18 15:02:16 <Miller> well, they tried to make it Cartesian (factor it into separate, insulated functions)
Mar 18 15:02:22 <carmen> plus you coudl record patch creation and play it back in slow motion, to demo or teach..
Mar 18 15:02:50 <Miller> ... and it turns out that sometimes the 'elegant' way is more complicated than the direct way.
Mar 18 15:03:14 <-- andree has quit ()
Mar 18 15:04:01 <Miller> carmen: you mean there was actually a patching language that used OSC to communicated patch changes?
Mar 18 15:04:30 <matju> carmen: the theoretical model of IMPD (Model/View) supports multi-client, but the actual IMPD doesn't support it yet.
Mar 18 15:05:12 <Miller> (organizational) Am I the only one on the west coast? Perhaps next time we should start an hour earlier...
Mar 18 15:05:23 <carmen> http://www.nongnu.org/om-synth/ uses that technique, it seems rather similar to the current pd-gui arrangemetn otherwise, mouse clicks on one, would generate the 'move coorrds' to 2 different clients..
Mar 18 15:05:58 <IOhannes> miller: would be very nice, as i am getting very tired and faint from hunger by now
Mar 18 15:06:10 <carmen> cya..
Mar 18 15:08:03 <matju> Miller: why would it one hour earlier ? do you need it?
Mar 18 15:08:17 <Miller> No, I think folks in Graz and Poland need it.
Mar 18 15:08:46 <matju> ok, so that they can go out in the evening?
Mar 18 15:09:00 <matju> it can also be another day than friday
Mar 18 15:09:08 <matju> i'm open to suggestions
Mar 18 15:09:12 <alx1> matju: so they can eat / leave work / sleep
Mar 18 15:09:41 <Miller> Friday is for for me, don't know about others...
Mar 18 15:09:55 <Miller> (sorry, meant, 'fine for me')
Mar 18 15:10:24 <IOhannes> ok for me too
Mar 18 15:10:31 <Miller> BTW, it's very useful to put a reminder out the evening before - I would have forgotten otherwise.
Mar 18 15:11:01 <matju> alx1: well, how is 5pm better than 6pm for them? when do they finish their day job?
Mar 18 15:11:12 <IOhannes> and i have forgotten to put a news ticker onto puredata.info (in case anybody reads that)
Mar 18 15:11:37 <IOhannes> matju: it is better for me (and it is my timezone)
Mar 18 15:11:44 <Miller> I think it's now 9PM in Graz.
Mar 18 15:11:48 <IOhannes> cannot speak for the others though
Mar 18 15:11:51 <IOhannes> miller: yes
Mar 18 15:11:59 <alx1> matju: it might be 9 over there now?
Mar 18 15:12:12 <IOhannes> alx1: it is
Mar 18 15:12:15 <matju> er, i meant 6pm vs 8pm, the start of the meeting
Mar 18 15:12:27 <matju> er, i meant 6pm vs 7pm, the start of the meeting (GAAH)
Mar 18 15:12:44 <IOhannes> well, it would be 8pm by now (which is better)
Mar 18 15:12:46 <matju> alx1: yes it is.
Mar 18 15:12:53 <matju> ok, cool.
Mar 18 15:13:19 <Miller> Right, I think people in German-speaking lands normally eat supper around 6 or 6:30.
Mar 18 15:13:34 <matju> actually, i almost scheduled this one for UTC17 like the last one, but i told myself i'd one more hour of sleep or something... =)
Mar 18 15:13:43 <IOhannes> but that'll be 9am in s.diego; don't they ever sleep
Mar 18 15:14:12 <IOhannes> and i tend to have supper at 9pm30
Mar 18 15:14:16 <Miller> ( AM is fine... I'm working from home today.
Mar 18 15:14:47 <Miller> (9 AM I mean).
Mar 18 15:15:33 <IOhannes> ok, so we'll meet again in 2 (or 3) weeks 17UTC
Mar 18 15:15:42 <Miller> sehr gut
Mar 18 15:15:42 <IOhannes> ?
Mar 18 15:16:03 <IOhannes> meine schoene zusammenfassung ??
Mar 18 15:16:49 <IOhannes> if this is ok for the rest of you, i will leave now
Mar 18 15:17:02 <matju> yeah
Mar 18 15:17:12 <matju> but still a friday ?
Mar 18 15:17:22 <alx1> IOhannes: bon appetit
Mar 18 15:17:22 <Miller> yeah
Mar 18 15:17:22 <IOhannes> thought so
Mar 18 15:17:32 <matju> ok then
Mar 18 15:17:39 <IOhannes> jamie: sorry we couldn't talk about the pdcon-text
Mar 18 15:17:43 <Miller> Thanks for organizing this.
Mar 18 15:17:49 <tigital> IOhannes: cya, we'll catch up later
Mar 18 15:18:07 <IOhannes> jamie: but i think they would prefer something "not that technical"
Mar 18 15:18:28 <tigital> ok, let's chat email-wise
Mar 18 15:18:36 <IOhannes> it is meant for all kind of people, mostly from the art-scences (the galerists in graz don't know openGL ;-)
Mar 18 15:18:40 <matju> Miller: there are too many questions i haven't asked, but then, if we call this meeting done, i'll keep them for next time
Mar 18 15:18:54 <IOhannes> jamie: gread itea
Mar 18 15:19:01 <IOhannes> ok
Mar 18 15:19:02 <IOhannes> bye
Mar 18 15:19:17 <Miller> yeah... maybe 2 weeks and not 3 then? (I'm getting hungry too...)
Mar 18 15:19:47 <tigital> miller: lunch was good over on this side of the divide ;-)
Mar 18 15:19:56 <matju> Miller: ok
Mar 18 15:20:13 <-- IOhannes has quit ("starving")
Mar 18 15:20:19 <matju> Miller: but that makes it April 1st ;-)
Mar 18 15:20:21 <-- mold (~morbid_d@bzq-82-80-216-40.red.bezeqint.net) has left #dataflow
Mar 18 15:20:46 <-- aalex has quit (Remote closed the connection)
Mar 18 15:20:58 <matju> Miller: as in http://iem.at/mailinglists/pd-list/2004-04/018850.html
Mar 18 15:21:19 --- matju has changed the topic to: The Diagram Is The Program (tm) | http://puredata.info/ | http://gridflow.ca/ | PureData Developers Meeting Friday April 1st at UTC17 (Quebec:12;California:9;CEurope:18)
Mar 18 15:21:27 --> aalex (~aalex@65.94.92.145) has joined #dataflow
Mar 18 15:21:45 <-- tigital has quit ()
Mar 18 15:21:54 <Miller> matju: April 1 is my favorite day of the year...
Mar 18 15:22:48 <aalex> What kind of tricks do you play? :)
Mar 18 15:23:12 <Miller> write wierd software.
Mar 18 15:24:22 * mamalala waits for pd 1.04
Mar 18 15:24:29 <matju> Miller: weird software? is that like the pute() function in d_soundfiler.c ?
Mar 18 15:24:51 <Miller> Forgot that one:)
Mar 18 15:25:05 <Miller> It must have just been a typo.
Mar 18 15:25:17 <matju> Miller: also did you find the name "pd" on an April 1st ?
Mar 18 15:25:49 <Miller> you know, in French it's more polite to use the French acronym, dp.
Mar 18 15:26:12 <aalex> data pure ?
Mar 18 15:26:17 <Miller> donnees pures
Mar 18 15:26:25 <aalex> *hehe*
Mar 18 15:26:41 <minDfrqnc> dp looks more beautiful compared to pd
Mar 18 15:26:42 <aalex> digital processer
Mar 18 15:26:48 <aalex> yes
Mar 18 15:26:49 <minDfrqnc> they are both beautiful letter combinations though
Mar 18 15:26:55 <Miller> or, 'dopo parigi'
Mar 18 15:26:59 <aalex> well, not in french
Mar 18 15:27:16 <aalex> pederaste...
Mar 18 15:27:36 <Miller> anyhow, pd's in the King's English, hurrah.
Mar 18 15:27:43 --> wip2 (~wip@Kitchener-HSE-ppp3579544.sympatico.ca) has joined #dataflow
Mar 18 15:28:05 <matju> Miller: it's difficult to convince frenchies that "pd" should be pronounced "dépé" and not "pédé".
Mar 18 15:29:02 <matju> Miller: on the pdmtl meeting #1 someone made a reservation saying "moi j'aimerais bien y assister, à la rencontre de pédés"
Mar 18 15:29:17 <Miller> When I get around to making a nice 'pd' icon I mean to nationalize it somehow so that it turns around in French countries.
Mar 18 15:29:19 <matju> Miller: btw i'm in iso-latin-1. are you?
Mar 18 15:29:28 <Miller> I have no idea...
Mar 18 15:29:45 <matju> Miller, if you turn "pd" 180 degrees, it makes "pd" again.
Mar 18 15:30:04 <Miller> yeas, that's part of the joke.
Mar 18 15:30:29 <Miller> Also if capitalized correctly: Pd ... which should become, "dP"
Mar 18 15:30:38 <matju> aalex: "dp" could be pronounced "dope" ;-)
Mar 18 15:30:53 <Miller> or 'deep' or 'dupe'
Mar 18 15:31:35 <matju> or "the software formerly known as «PÉDÉ»"
Mar 18 15:31:48 <Miller> nice idea, that one.
Mar 18 15:31:54 <matju> Miller: if you see my accents correctly you're in iso-latin-1
Mar 18 15:31:58 <aalex> I say "pay day"
Mar 18 15:32:04 <Miller> I haven't seen any accents from anyone.
Mar 18 15:32:08 <aalex> im in utf8...
Mar 18 15:32:14 <matju> aalex: but not with an English accent?
Mar 18 15:32:14 <aalex> pédé
Mar 18 15:32:38 <matju> aalex is in utf-8
Mar 18 15:33:06 <aalex> did you see mines ? Miller
Mar 18 15:33:20 <Miller> OK, will have to figure out which is the best character set someday. Anyhow, I'm ready for lunch
Mar 18 15:33:30 <Miller> aales: no, I dont
Mar 18 15:33:31 <matju> Miller: ok, good lunch then =)
Mar 18 15:33:45 <Miller> bye all.
Mar 18 15:33:52 <aalex> ciao
Mar 18 15:33:52 <mamalala> bye Miller
Mar 18 15:33:55 <-- Miller has quit ("Leaving")


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