I have a very useful patch generating 3d shapes from various types of
user input. The problem of course arises when I have created too many
objects on screen, at which point I want to start deleting the oldest,
sort of like note-stealing in synth terminology.

I’ve gotten as far as figuring out sort of how to look for the info in
cmdlist, parsing it, etc, but I was wondering if any of you had some
interesting abstractions for this kind of processing?

Also, and this is probably very basic really, but what is the proper way
to store this cmdlist info in presets? Is it as simple as using message
getcmdlist and sending the cmdlist to pattrstorage or whatever, and then
inserting it again with cmd_insert?

I found this abstraction – is this the way to go?

http://www.pelado.co.uk/?p=37

Cheers for any insights – I feel like I’m right on the brink of some
funky stuff :-)

Andreas.

just now i found a piece of window program called GLintercapt
http://glintercept.nutty.org/screenshot.html that intercept calls from any
program to the opengl driver. debuggind opengl is still a bit of a mystery
to me.
i couldnt get it to do everything it calims but did get a frame by frame
dump of jitter calls to the driver, very informative
there are commercial solutions that offer more but they cost ~670$ per seat.

http://www.gremedy.com/

On 12/26/06, Andreas Wetterberg wrote:
>
> Hi,
>
> I have a very useful patch generating 3d shapes from various types of
> user input. The problem of course arises when I have created too many
> objects on screen, at which point I want to start deleting the oldest,
> sort of like note-stealing in synth terminology.
>
> I’ve gotten as far as figuring out sort of how to look for the info in
> cmdlist, parsing it, etc, but I was wondering if any of you had some
> interesting abstractions for this kind of processing?
>
> Also, and this is probably very basic really, but what is the proper way
> to store this cmdlist info in presets? Is it as simple as using message
> getcmdlist and sending the cmdlist to pattrstorage or whatever, and then
> inserting it again with cmd_insert?
>
> I found this abstraction – is this the way to go?
> http://www.pelado.co.uk/?p=37
>
> Cheers for any insights – I feel like I’m right on the brink of some
> funky stuff :-)
>
> Andreas.
>

Perhaps that can offer some direction.

On Dec 26, 2006, at 2:02 PM, Andreas Wetterberg wrote:

> Dear Yair,
> yes, I’ve been through the help files already (I have even gone as
> far as to copy [p cmdlist_commands] to my own patch for easy
> access), and I was well aware of the commands, but seeing as my
> cmdlist contains hundreds of entries I was looking for ways to
> automate the process, having each entry automatically catalogued
> elsewhere for editing and re-upping to jit.gl.sketch.
>
> It “sort of” looks like p.jit.gl.sketch *again, found here: http://
> http://www.pelado.co.uk/?p=37 * is the way to go for me as far as saving/
> loading “presets” from jit.gl.sketch, but for now, unless someone
> has a brilliant idea, I will go with a homebrew routing abstraction.
>
> I will share it if I am succesful.
>
> Thanks,
> Andreas.
>
> yair reshef skrev:
>> you can cmd_delete, cmd_replace and cmd_insert commands into the
>> cmd list. it is coverd in the sketch help file. i hope you went
>> thru that, i share your passion for cmd list, but beware, not
>> reseting the list from timetotime or storing it on the gpu with
>> displaylist 1 will slow you down. grab a copy of the opengl
>> referance, and look into it. modelview and displaylist
>>
>>
>> just now i found a piece of window program called GLintercapt
>> http://glintercept.nutty.org/screenshot.html that intercept calls
>> from any program to the opengl driver. debuggind opengl is still a
>> bit of a mystery to me.
>> i couldnt get it to do everything it calims but did get a frame by
>> frame dump of jitter calls to the driver, very informative
>> there are commercial solutions that offer more but they cost ~670$
>> per seat. http://www.gremedy.com/
>>
>>
>>
>> On 12/26/06, Andreas Wetterberg
>> wrote:
>> Hi,
>>
>> I have a very useful patch generating 3d shapes from various types of
>> user input. The problem of course arises when I have created too
>> many
>> objects on screen, at which point I want to start deleting the
>> oldest,
>> sort of like note-stealing in synth terminology.
>>
>> I’ve gotten as far as figuring out sort of how to look for the
>> info in
>> cmdlist, parsing it, etc, but I was wondering if any of you had some
>> interesting abstractions for this kind of processing?
>>
>> Also, and this is probably very basic really, but what is the
>> proper way
>> to store this cmdlist info in presets? Is it as simple as using
>> message
>> getcmdlist and sending the cmdlist to pattrstorage or whatever,
>> and then
>> inserting it again with cmd_insert?
>>
>> I found this abstraction – is this the way to go?
>> http://www.pelado.co.uk/?p=37
>>
>> Cheers for any insights – I feel like I’m right on the brink of some
>> funky stuff :-)
>>
>> Andreas.
>>
>>
>

v a d e //

http://www.vade.info
abstrakt.vade.info

On 12/26/06, vade wrote:
>
> Ive seen (but havent done it myself) many people use coll to manage the
> command list entries, and then dump the coll once they have completed the
> list as they want it.
> Perhaps that can offer some direction.
>
> On Dec 26, 2006, at 2:02 PM, Andreas Wetterberg wrote:
>
> Dear Yair,
> yes, I’ve been through the help files already (I have even gone as far as
> to copy [p cmdlist_commands] to my own patch for easy access), and I was
> well aware of the commands, but seeing as my cmdlist contains hundreds of
> entries I was looking for ways to automate the process, having each entry
> automatically catalogued elsewhere for editing and re-upping to
> jit.gl.sketch.
>
> It “sort of” looks like p.jit.gl.sketch *again, found here:
> http://www.pelado.co.uk/?p=37 * is the way to go for me as far as
> saving/loading “presets” from jit.gl.sketch, but for now, unless someone
> has a brilliant idea, I will go with a homebrew routing abstraction.
>
> I will share it if I am succesful.
>
> Thanks,
> Andreas.
>
> yair reshef skrev:
>
> you can cmd_delete, cmd_replace and cmd_insert commands into the cmd list.
> it is coverd in the sketch help file. i hope you went thru that, i share
> your passion for cmd list, but beware, not reseting the list from timetotime
> or storing it on the gpu with displaylist 1 will slow you down. grab a copy
> of the opengl referance, and look into it. modelview and displaylist
>
>
> just now i found a piece of window program called GLintercapt
> http://glintercept.nutty.org/screenshot.html that intercept calls from any
> program to the opengl driver. debuggind opengl is still a bit of a mystery
> to me.
> i couldnt get it to do everything it calims but did get a frame by frame
> dump of jitter calls to the driver, very informative
> there are commercial solutions that offer more but they cost ~670$ per
> seat. http://www.gremedy.com/
>
>
>
> On 12/26/06, Andreas Wetterberg wrote:
> >
> > Hi,
> >
> > I have a very useful patch generating 3d shapes from various types of
> > user input. The problem of course arises when I have created too many
> > objects on screen, at which point I want to start deleting the oldest,
> > sort of like note-stealing in synth terminology.
> >
> > I’ve gotten as far as figuring out sort of how to look for the info in
> > cmdlist, parsing it, etc, but I was wondering if any of you had some
> > interesting abstractions for this kind of processing?
> >
> > Also, and this is probably very basic really, but what is the proper way
> > to store this cmdlist info in presets? Is it as simple as using message
> > getcmdlist and sending the cmdlist to pattrstorage or whatever, and then
> > inserting it again with cmd_insert?
> >
> > I found this abstraction – is this the way to go?
> > http://www.pelado.co.uk/?p=37
> >
> > Cheers for any insights – I feel like I’m right on the brink of some
> > funky stuff :-)
> >
> > Andreas.
> >
>
> ——————————
>
>
>
>
> *v a d e //*
>
> *www.vade.info*
> *abstrakt.vade.info*
>
>
>
>
>
>
>

On 12/27/06, yair reshef wrote:
>
> i guess it all goes down to the kind of database max offers.and opengl
> accepts. coll is the usual suspect and the one tilored made for the job of
> storing symbol lists.
> it is not tuned for parentingsubtrees etc. (sure there r more techincal
> words for this or other views)
> a clearer idea of what your doing in your sketch will help , are they
> grouped in any way? completly random?
>
> On 12/26/06, vade < doktorp@mac.com> wrote:
> >
> > Ive seen (but havent done it myself) many people use coll to manage the
> > command list entries, and then dump the coll once they have completed the
> > list as they want it.
> > Perhaps that can offer some direction.
> >
> > On Dec 26, 2006, at 2:02 PM, Andreas Wetterberg wrote:
> >
> > Dear Yair,
> > yes, I’ve been through the help files already (I have even gone as far
> > as to copy [p cmdlist_commands] to my own patch for easy access), and I was
> > well aware of the commands, but seeing as my cmdlist contains hundreds of
> > entries I was looking for ways to automate the process, having each entry
> > automatically catalogued elsewhere for editing and re-upping to
> > jit.gl.sketch.
> >
> > It “sort of” looks like p.jit.gl.sketch *again, found here: http://www.pelado.co.uk/?p=37
> > * is the way to go for me as far as saving/loading “presets” from
> > jit.gl.sketch, but for now, unless someone has a brilliant idea, I will
> > go with a homebrew routing abstraction.
> >
> > I will share it if I am succesful.
> >
> > Thanks,
> > Andreas.
> >
> > yair reshef skrev:
> >
> > you can cmd_delete, cmd_replace and cmd_insert commands into the cmd
> > list. it is coverd in the sketch help file. i hope you went thru that, i
> > share your passion for cmd list, but beware, not reseting the list from
> > timetotime or storing it on the gpu with displaylist 1 will slow you down.
> > grab a copy of the opengl referance, and look into it. modelview and
> > displaylist
> >
> >
> > just now i found a piece of window program called GLintercapt
> > http://glintercept.nutty.org/screenshot.html that intercept calls from
> > any program to the opengl driver. debuggind opengl is still a bit of a
> > mystery to me.
> > i couldnt get it to do everything it calims but did get a frame by frame
> > dump of jitter calls to the driver, very informative
> > there are commercial solutions that offer more but they cost ~670$ per
> > seat. http://www.gremedy.com/
> >
> >
> >
> > On 12/26/06, Andreas Wetterberg < awetterberg@post.cybercity.dk > wrote:
> > >
> > > Hi,
> > >
> > > I have a very useful patch generating 3d shapes from various types of
> > > user input. The problem of course arises when I have created too many
> > > objects on screen, at which point I want to start deleting the oldest,
> > > sort of like note-stealing in synth terminology.
> > >
> > > I’ve gotten as far as figuring out sort of how to look for the info in
> > >
> > > cmdlist, parsing it, etc, but I was wondering if any of you had some
> > > interesting abstractions for this kind of processing?
> > >
> > > Also, and this is probably very basic really, but what is the proper
> > > way
> > > to store this cmdlist info in presets? Is it as simple as using
> > > message
> > > getcmdlist and sending the cmdlist to pattrstorage or whatever, and
> > > then
> > > inserting it again with cmd_insert?
> > >
> > > I found this abstraction – is this the way to go?
> > > http://www.pelado.co.uk/?p=37
> > >
> > > Cheers for any insights – I feel like I’m right on the brink of some
> > > funky stuff :-)
> > >
> > > Andreas.
> > >
> >
> > ——————————
> >
> >
> >
> >
> >
> > * v a d e //*
> >
> > * http://www.vade.info*
> > * abstrakt.vade.info*
> >
> >
> >
> >
> >
> >
> >
>

After a longer hiatus from this problem I finally sat down and had a good think, and whaddyaknow – it’s not that difficult. No colls, no weird stacking of thingumajigs.

Here’s my solution, a nice little subpatcher, ready to hook up to outlet 2 of jit.gl.sketch.

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 351 540 92 9109513 prepend cmd_delete;
#P newex 351 515 38 9109513 zl iter 1;
#N comlet please delete these;
#P outlet 351 569 15 0;
#P newex 558 521 49 9109513 print keep;
#P newex 440 519 86 9109513 print please_delete;
#P message 392 452 18 9109513 $1;
#N vpatcher 25 70 625 470;
#P window setfont “Sans Serif” 9.;
#P window linecount 0;
#P newex 379 143 44 9109513 r objpoly;
#P button 313 66 15 0;
#P window linecount 1;
#P comment 253 308 100 9109513 keep these;
#P comment 371 246 100 9109513 delete this many;
#P window linecount 2;
#P comment 368 189 100 9109513 delete all above this number of values;
#P number 367 227 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P newex 265 200 62 9109513 expr $i1 – $i2;
#P newex 206 283 36 9109513 zl slice;
#P button 50 176 15 0;
#P newex 93 157 52 9109513 thresh 100;
#P newex 75 203 30 9109513 zl reg;
#P message 319 88 14 9109513 0;
#P number 300 153 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#N counter;
#X flags 0 0;
#P newobj 278 115 66 9109513 counter;
#P message 63 50 117 9109513 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , 10;
#P window linecount 2;
#P comment 196 149 100 9109513 number of incoming values;
#P window linecount 1;
#P comment 98 310 100 9109513 delete these;
#N comlet input stream of values to thresh count and slice;
#P inlet 221 34 15 0;
#N comlet input resets counter;
#P inlet 313 46 15 0;
#N comlet input triggers compiled list to be sliced;
#P inlet 50 156 15 0;
#N comlet keep these;
#P outlet 232 307 15 0;
#N comlet Delete these;
#P outlet 206 307 15 0;
#P connect 2 0 13 0;
#P connect 13 0 11 0;
#P connect 4 0 12 0;
#P connect 7 0 12 0;
#P connect 12 0 11 1;
#P connect 11 0 14 0;
#P connect 14 0 0 0;
#P connect 15 0 14 1;
#P connect 14 1 1 0;
#P connect 9 0 15 0;
#P connect 4 0 8 0;
#P connect 7 0 8 0;
#P connect 8 0 9 0;
#P connect 3 0 20 0;
#P connect 21 0 15 1;
#P connect 20 0 10 0;
#P connect 10 0 8 3;
#P connect 15 0 16 0;
#P pop;
#P newobj 361 483 128 9109513 p sliceCounter;
#P newex 82 411 19 9109513 t b;
#P newex 194 493 127 9109513 prepend number_of_objects:;
#P newex 344 140 27 9109513 t b b;
#P newex 275 191 44 9109513 print end;
#P number 108 466 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 194 470 27 9109513 int;
#P newex 335 111 73 9109513 sel cmdlist_end;
#P newex 167 154 51 9109513 print begin;
#P newex 223 319 19 9109513 t 0;
#N counter;
#X flags 0 0;
#P newobj 148 435 66 9109513 counter;
#P newex 223 111 80 9109513 sel cmdlist_begin;
#P newex 135 350 70 9109513 prepend ellipse;
#P newex 120 327 91 9109513 prepend framecircle;
#P newex 105 304 66 9109513 prepend circle;
#P newex 90 279 65 9109513 prepend torus;
#P newex 75 253 66 9109513 prepend lineto;
#P newex 60 228 58 9109513 prepend line;
#P newex 45 203 77 9109513 prepend cylinder;
#P newex 30 180 72 9109513 prepend sphere;
#P newex 15 157 64 9109513 prepend cube;
#P newex 0 130 66 9109513 prepend plane;
#P newex 46 378 36 9109513 zl rot 1;
#P outlet 46 522 15 0;
#P window linecount 2;
#P newex 0 79 160 9109513 route plane cube sphere cylinder line lineto torus circle framecircle ellipse;
#P window linecount 1;
#P newex 1 57 39 9109513 zl rot -2;
#P inlet 179 22 15 0;
#P window linecount 14;
#P comment 458 172 100 9109513 hook this up to jit.gl.sketch and send it a [getcmdlist] command. The route object will catch the objects (did I forget any?) and then they will be counted and sent to a zl slice. This generates a list of “outcasts” which will be iterated with a “prepend cmd_delete ” out outlet 2.;
#P window linecount 8;
#P comment 460 57 100 9109513 This patch was made to control the “polymorphy” of jit.gl.sketch. It will automatically delete the oldest object if you exceed the user set poly-value.;
#P window linecount 1;
#P comment 486 581 192 9109513 (c) Wetterberg – a@TheCovertOperators.org;
#P connect 4 0 5 0;
#P connect 5 0 8 0;
#P fasten 3 0 4 0 184 41 6 41;
#P connect 5 1 9 0;
#P connect 5 2 10 0;
#P connect 5 3 11 0;
#P fasten 8 0 7 0 5 263 51 263;
#P fasten 9 0 7 0 20 277 51 277;
#P fasten 10 0 7 0 35 288 51 288;
#P fasten 11 0 7 0 50 300 51 300;
#P fasten 12 0 7 0 65 312 51 312;
#P fasten 13 0 7 0 80 325 51 325;
#P fasten 14 0 7 0 95 338 51 338;
#P fasten 15 0 7 0 110 350 51 350;
#P fasten 16 0 7 0 125 362 51 362;
#P fasten 17 0 7 0 140 373 51 373;
#P connect 7 0 6 0;
#P fasten 27 0 6 0 199 517 51 517;
#P connect 5 4 12 0;
#P connect 5 5 13 0;
#P connect 7 0 28 0;
#P connect 5 6 14 0;
#P connect 5 7 15 0;
#P fasten 19 0 24 0 153 460 113 460;
#P connect 5 8 16 0;
#P connect 5 9 17 0;
#P fasten 28 0 19 0 87 432 153 432;
#P fasten 18 0 21 0 228 142 172 142;
#P fasten 20 0 19 3 228 386 195 386;
#P fasten 26 1 23 0 366 458 199 458;
#P connect 23 0 27 0;
#P connect 19 0 23 1;
#P fasten 3 0 18 0 184 68 228 68;
#P connect 18 0 20 0;
#P fasten 26 0 25 0 349 175 280 175;
#P fasten 3 0 22 0 184 68 340 68;
#P fasten 22 0 26 0 340 135 349 135;
#P fasten 29 0 34 0 366 508 356 508;
#P connect 34 0 35 0;
#P connect 35 0 33 0;
#P connect 26 1 29 0;
#P connect 7 0 30 0;
#P lcolor 2;
#P connect 30 0 29 1;
#P fasten 29 0 31 0 366 508 445 508;
#P connect 26 0 29 2;
#P lcolor 7;
#P fasten 29 1 32 0 484 511 563 511;
#P window clipboard copycount 36;