[PD-cvs] pd/src TODO,1.1.2.25,1.1.2.26
Mathieu Bouchard
matju at users.sourceforge.net
Tue Nov 28 01:36:53 CET 2006
Update of /cvsroot/pure-data/pd/src
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv11702
Modified Files:
Tag: devel_0_39
TODO
Log Message:
.
Index: TODO
===================================================================
RCS file: /cvsroot/pure-data/pd/src/Attic/TODO,v
retrieving revision 1.1.2.25
retrieving revision 1.1.2.26
diff -C2 -d -r1.1.2.25 -r1.1.2.26
*** TODO 27 Nov 2006 22:51:50 -0000 1.1.2.25
--- TODO 28 Nov 2006 00:36:51 -0000 1.1.2.26
***************
*** 104,127 ****
[ ] try libentity
[ ] try vtk-tcl
-
- [ ] symbol vs strings: Ruby is right: the Symbol vs String distinction is annoying and possibly obsolete.
- according to me, symbols exist mostly because LISP had them before they had strings, and because most
- Strings implementations aren't powerful enough to be as fast (or almost as fast) as Symbols.
- (well, for compatibility reasons, just like in Ruby, we can't remove symbol support completely, but
- at least we can reduce the difference between strings and symbols to a minimum.)
-
- [ ] server-side IEMGUI could be turned into Tcl-based externs OR EVEN become abstractions.
- it's possible to make a DesireData GUI for any Pd class, including abstractions.
- to turn IEMGUI into an abstraction, what's missing is the savefn/saveargs/scanargs business.
-
- [ ] I would like to know how much it is feasible to compress the t_atom
- structure so that even with 64-bit pointers the t_atom still stays 8 bytes
- instead of 16. I think it's possible, but not necessarily in a
- backwards-compatible way, and not necessarily in a portable way. also maybe it's not that useful.
-
- 07:24 <matju> however we could make it different by inserting the splashscreen inside the main window
- 07:25 <matju> or we could make it a separate window but no timer, just an [OK] button, so actually, this would be
- exactly the same as the "About" dialog.
-
[ ] make sure $0 actually works (see canvas_realizedollar)
[ ] test rcv_able, snd_able
--- 104,107 ----
***************
*** 162,190 ****
[ ] insert_object makes error with multiple selection.
[ ] popup_properties on multiple selection.
! [ ]
!
! <zkink> as well as select multiple wires, or multiple objects, and color code them
! <zkink> if you do segmented patchchords, it needs some functions:
! <zkink> a hotkey to click on the chord, and add a new segment
! <zkink> a hotkey to drag the "points" (where two lines meet)
! <zkink> a modifier key to delete a segment (actually the others should be that way too)
! <zkink> and: you should be able to right click on a regular patchchord, and press "segment"
! <zkink> or do a hotkey with it
! <zkink> and it automatically turns it into an straight-elbow multisegmented chord
! <zkink> like _| instead of /
! <zkink> it makes it into three lines: _|~
!
[ ] [t a] could be a very small GUI object (called "null object")
[ ] all the [t] could be GUI objects
[ ] GUI objects for [inlet] and [outlet] and [pd] ([page])
- <zkink> PERHAPS, a hack for multisegmented patchchords, would be to make a null object
- <zkink> a null object is an actual object that just looks like a .
- <zkink> and wires can connect to it
- <zkink> next: SUBPATCHERIZE SELECTION. you select a number of objects with your mouse
- <zkink> and you right click and press subpatcherize
- <zkink> it puts all the objects you have selected into a subpatcher, and it automatically wires up INLETS/outlets
- <zkink> so that the code is exactly the same, its just in a subpatcher instead
- <zkink> after the subpatcher is created, it leaves you with a new object, with the text focus waiting for you to type its name
<zkink> next: move ALL functions from the command line into a Options box.
<zkink> options box should save a PD config file
--- 142,176 ----
[ ] insert_object makes error with multiple selection.
[ ] popup_properties on multiple selection.
! [ ] segmented patchcords:
! [ ] a hotkey to click on the cord, and add a new segment
! [ ] a hotkey to drag the "points" (where two lines meet)
! [ ] a modifier key to delete a segment (actually the others should be that way too)
! [ ] you should be able to right click on a regular wire, and press "segment" or do a hotkey with it
! and it automatically turns it into an straight-elbow multisegmented wire
[ ] [t a] could be a very small GUI object (called "null object")
[ ] all the [t] could be GUI objects
[ ] GUI objects for [inlet] and [outlet] and [pd] ([page])
+ [ ] subpatcherize selection
+ <zkink> after it's created, it leaves you with a new object, with the text focus waiting for you to type its name
+
+ [ ] symbol vs strings: Ruby is right: the Symbol vs String distinction is annoying and possibly obsolete.
+ according to me, symbols exist mostly because LISP had them before they had strings, and because most
+ Strings implementations aren't powerful enough to be as fast (or almost as fast) as Symbols.
+ (well, for compatibility reasons, just like in Ruby, we can't remove symbol support completely, but
+ at least we can reduce the difference between strings and symbols to a minimum.)
+
+ [ ] server-side IEMGUI could be turned into Tcl-based externs OR EVEN become abstractions.
+ it's possible to make a DesireData GUI for any Pd class, including abstractions.
+ to turn IEMGUI into an abstraction, what's missing is the savefn/saveargs/scanargs business.
+
+ [ ] I would like to know how much it is feasible to compress the t_atom
+ structure so that even with 64-bit pointers the t_atom still stays 8 bytes
+ instead of 16. I think it's possible, but not necessarily in a
+ backwards-compatible way, and not necessarily in a portable way. also maybe it's not that useful.
+
+ 07:24 <matju> however we could make it different by inserting the splashscreen inside the main window
+ 07:25 <matju> or we could make it a separate window but no timer, just an [OK] button, so actually, this would be
+ exactly the same as the "About" dialog.
<zkink> next: move ALL functions from the command line into a Options box.
<zkink> options box should save a PD config file
***************
*** 194,230 ****
<matju> the NULL object looks like jMax's [fork] except with only one outlet
<matju> or almost like [t a]
! <zkink> that would work as a makeshift plan for multisegmented chords
<matju> except [t a] is more like "list $1" and converts scalars into 1-element lists (yuck)
<zkink> since its compatible with the current pd fileformat
<zkink> it can be tiny: 3 pixels by 3 pixels
<zkink> just a little DOT
! <zkink> OK, now as I was saying
! <zkink> data inspector:
! <zkink> when this tool is enabled, it prints on the console any data coming through whatever cable you currently have selected
! <zkink> and if you select multiple chords
! <zkink> it reports whats going through multiple chords
! <matju> zkink: well, actually, segmented patchcords are compatible with the .pd format. try adding stuff in a #X connect line, before the semicolon
! <matju> zkink: (it's just that Pd doesn't save that stuff back...)
! <zkink> so: example
! <zkink> SNIFFER: list: 10 10 10 1 66
! <zkink> SNIFFER: int: 4
! <zkink> SNIFFER: message: boop
! <zkink> SNIFFER: bang
! <matju> data inspector looks like a jMax [display] but a bit like the console too, right?
! <zkink> well i'm not sure, i should install Jmax
! <matju> a kind of [print] but to a miniconsole?
! <zkink> well, its just a toggle, you toggle it ON/Off
! <zkink> when its ON, it reports whats going through ANY patchchord you have "highlighted"
! <matju> [display] is roughly like [prepend set] -> ""
! <matju> where "" is an empty message box
! <zkink> well, print isnt good enough, it doesnt tell you the data type
! <matju> and [prepend] is from zexy or cyclone...
! <matju> you mean the selector?
! <zkink> selector ? wozzat
! <matju> selector is the message header
! <zkink> sorry i'm not sure what you mean, i've been using max
! <matju> sorry i'm not sure what you mean, i've been using jmax
! <zkink> selector is just the datatype ? before the message? in the packet
! <zkink> yeah, it would report that. it just tells you whats goin thru lines
<zkink> next: you need a way to see cpu usage on individual objects
<zkink> or on patchers or on groups of selected objects
--- 180,193 ----
<matju> the NULL object looks like jMax's [fork] except with only one outlet
<matju> or almost like [t a]
! <zkink> that would work as a makeshift plan for multisegmented wires
<matju> except [t a] is more like "list $1" and converts scalars into 1-element lists (yuck)
<zkink> since its compatible with the current pd fileformat
<zkink> it can be tiny: 3 pixels by 3 pixels
<zkink> just a little DOT
!
! [ ] data inspector: when this tool is enabled, it prints on the console any data coming through whatever cable you
! currently have selected. if you select multiple wires, it reports whats going through multiple wires.
! [ ] put [display] directly in DesireData
!
<zkink> next: you need a way to see cpu usage on individual objects
<zkink> or on patchers or on groups of selected objects
More information about the Pd-cvs
mailing list