P_Petrowiek

comments-in-patcher-as-text

> Is there a possibility to add comments in "patchers as text" in a similar

What about searching the manual for the word "comment"?

tworowski.sebastien@laposte.net wrote:
> Is there a possibility to add comments in "patchers as text" in a similar
> way ?

  [][]  [][][]  [][]  [][][]
[][][][][][][][][][][][][][][]

         Stefan Tiedje
         Klanggestalter
     Electronic Composition
               &
         Improvisation

            /~~~~~
     \   /|() ()|
     ))))) )|  |  |( \
     ///     _/)/ )))))
             ___/   ///

-------------------------x----
--_____-----------|-----------
--(_|_ ----|-----|-----()----
-- _|_)----|-----()-----------
----------()------------x-----

14, Av. Pr. Franklin Roosevelt,
94320 Thiais, France
Phone at CCMIX +33-1-57 42 91 09


On 26-Apr-2006, at 11:23, tworowski.sebastien@laposte.net wrote:

> it would bive something like this for example :

> #p blabla blla blabla 1234 9823 374 299 blabla //mon blabla

I almost sent the same reply as Stefan, but reread just in time... 

(particularly because I was sure Sebastien's Max chops are up to 

The Max text format is "not intended to be human-readable" (words to 

that effect have been posted several times over the decades by DDZ 

and, possibly, JKC), so the answer is probably "no".

There may be some more "secrets" skulking about, though.

#P foo baz 314 156259 374 42 hike; after-the-semi-ignored?

You could try that but I think the Max parser will behave tiresomely 

if there is non-patcher commentary after the semi-colon.

OK: Jeremy, Joshua, David: this is your cue to prove me wrong.

Peter Castine +--> Litter Power & Litter Bundle for Jitter

iCE: Sequencing, Recording & |home | chez nous|

Interface Building for |bei uns | i nostri|

On 26-Apr-2006, at 11:23, tworowski.sebastien@laposte.net wrote:
> Ok but that's not what i mean !!!
>
> it would bive something like this for example :
> #p blabla blla blabla 1234 9823 374 299 blabla //mon blabla
>
> See ?
> Nothing to do with the comment object.

I almost sent the same reply as Stefan, but reread just in time...  
(particularly because I was sure Sebastien's Max chops are up to  
comment boxes, and more!)

The Max text format is "not intended to be human-readable" (words to  
that effect have been posted several times over the decades by DDZ  
and, possibly, JKC), so the answer is probably "no".

You could try that but I think the Max parser will behave tiresomely  
if there is non-patcher commentary after the semi-colon.

--------------    http://www.bek.no/~pcastine/Litter/    -------------
Peter Castine             +--> Litter Power & Litter Bundle for Jitter

On 26 Apr 2006, at 12:39, Peter Castine wrote:

> #P foo baz 314 156259 374 42 hike; after-the-semi-ignored?

> You could try that but I think the Max parser will behave 

> tiresomely if there is non-patcher commentary after the semi-colon.

As I recall, this text format is just a printable binbuf (if anyone 

remembers those), so newlines aren't significant; the I/O routines 

tend to put them in after semicolons. A quick hack-and-test seems to 

nick rothwell -- composition, systems, performance -- 

> #P foo baz 314 156259 374 42 hike; after-the-semi-ignored?
>
> You could try that but I think the Max parser will behave  
> tiresomely if there is non-patcher commentary after the semi-colon.

As I recall, this text format is just a printable binbuf (if anyone  
remembers those), so newlines aren't significant; the I/O routines  
tend to put them in after semicolons. A quick hack-and-test seems to  
confirm this.

   nick rothwell -- composition, systems, performance -- http:// 
www.cassiel.com


On 26-Apr-2006, at 14:55, Nick Rothwell wrote:

Indeedahdo. On'y last month we was talkin' 'bout 'em on a dev-list.

Figgerred as much. Woulda been a good way to fix up Seb's ahdear, 

> A quick hack-and-test seems to confirm this.

-- P. (seems to a been a-readin' Annie Proulx)

On 26-Apr-2006, at 14:55, Nick Rothwell wrote:
> binbuf (if anyone remembers those),

Figgerred as much. Woulda been a good way to fix up Seb's ahdear,  
though.

-- P. (seems to a been a-readin' Annie Proulx)


> I tried the possibility to write something after the ; at the end of each

> line but it changes all the connections and 

you can comment in a more sanely readable manner, but you have to adjust 

your connections at the same time. probably better to do this with some 

sort of automatic interface rather than by hand. the second patch below 

patch is functionally identical to the first, but it's more readable in 

text form. notice especially the way the connect lines change. the 

pattern is fairly obvious: object lines appear to be constructed as a 

stack beginning with index 0 (ie, lower numbers are lower on the page). 

on the other hand, as has been pointed out, this format may not be 

reliable... and this is a very simple example.

> I tried the possibility to write something after the ; at the end of each
> line but it changes all the connections and 
> messes up all the patch of course.

you can comment in a more sanely readable manner, but you have to adjust 
your connections at the same time.  probably better to do this with some 
sort of automatic interface rather than by hand.  the second patch below 
patch is functionally identical to the first, but it's more readable in 
text form.  notice especially the way the connect lines change.  the 
pattern is fairly obvious: object lines appear to be constructed as a 
stack beginning with index 0 (ie, lower numbers are lower on the page). 
  on the other hand, as has been pointed out, this format may not be 
reliable... and this is a very simple example.

Well done. Did you work that out by intelligent guessing or could you 

fall back on any written documentation (maybe more secrets)?

On 27-Apr-2006, at 10:39, dlurk wrote:
> 

Well done. Did you work that out by intelligent guessing or could you  
fall back on any written documentation (maybe more secrets)?

I use the text representation a lot. Not to edit but to search for sends/receives/grabs/colls/prints throughout my patch with a texteditor that has advanced search options (e.g. the textwrangler 'Find all' option). In fact I am just waiting for a 'Find all' option in Max.

Not really.. I use it mostly to change the name of a specific send/receive throughout the patch (the one I am working on now exceeds 85,000 lines in text). You guys ever tried the 'refactor' functionality in eclipse? (

 Now -that- is an IDE. I am afraid Max/MSP is not coming near. But I guess to make Max a real programming language with a real IDE is something for the future. A future I believe in though.

Not really.. I use it mostly to change the name of a specific send/receive throughout the patch (the one I am working on now exceeds 85,000 lines in text). You guys ever tried the 'refactor' functionality in eclipse? (http://www.eclipse.org/) Now -that- is an IDE. I am afraid Max/MSP is not coming near. But I guess to make Max a real programming language with a real IDE is something for the future. A future I believe in though.


> Well done. Did you work that out by intelligent guessing or could you

> fall back on any written documentation (maybe more secrets)?

i constructed the initial patch sequentially (the four numboxes then the 

four comments) in max, but then deleted the comment "box 1" and replaced 

it so that the creation order might be apparent in the text patch 

structure. i tried rearranging the text without changing the 

connections, and max kindly let me know that the connections were out of 

range. from memory of other patches-as-text, it seems there are always 

a bunch of objects and then a bunch of connections. that clued me in 

that the indexing of the connections might be related to the order of 

the objects. so then i changed the numbers in the connection lines, 

only to discover that the objects ended up wired in reverse order (ie 

box 2 outlet to box 1 inlet), so that meant that the object stack 

prepends rather than appends... generally but not consistently.

to address the last point more specifically: initially the object stack 

but then i deleted comment "box 1" and replaced it with an identical 

comment. and the following was the result:

so because of methodical patch construction, we know that max started at 

index-location 0-bottom and moved up from there. but when an object was 

deleted from that initial sequence, and then another object was added, 

perhaps the new creation sequence starts at the bottom again. does this 

mean that when this kind of edit happens, max has to re-index all the 

i have way too much day job to do today so i should stop playing with 

Peter Castine wrote:
 > Well done. Did you work that out by intelligent guessing or could you
 > fall back on any written documentation (maybe more secrets)?

i constructed the initial patch sequentially (the four numboxes then the 
four comments) in max, but then deleted the comment "box 1" and replaced 
it so that the creation order might be apparent in the text patch 
structure.  i tried rearranging the text without changing the 
connections, and max kindly let me know that the connections were out of 
range.  from memory of other patches-as-text, it seems there are always 
a bunch of objects and then a bunch of connections.  that clued me in 
that the indexing of the connections might be related to the order of 
the objects.  so then i changed the numbers in the connection lines, 
only to discover that the objects ended up wired in reverse order (ie 
box 2 outlet to box 1 inlet), so that meant that the object stack 
prepends rather than appends... generally but not consistently.

to address the last point more specifically: initially the object stack 
probably looked like this:

but then i deleted comment "box 1" and replaced it with an identical 
comment.  and the following was the result:

so because of methodical patch construction, we know that max started at 
index-location 0-bottom and moved up from there.  but when an object was 
deleted from that initial sequence, and then another object was added, 
perhaps the new creation sequence starts at the bottom again.  does this 
mean that when this kind of edit happens, max has to re-index all the 
connections?

i have way too much day job to do today so i should stop playing with 
it, but it's an interesting subject.

> Well done. Did you work that out by intelligent guessing or could you 

I think the order in the text version is the reverse order of creation. 

by deleting and undo you can change and kind of sort it...

Peter Castine wrote:
> Well done. Did you work that out by intelligent guessing or could you  
> fall back on any written documentation (maybe more secrets)?

I think the order in the text version is the reverse order of creation. 
by deleting and undo you can change and kind of sort it...
But for sure its not worth the hassle...

> I use the text representation a lot. Not to edit but to search for

> sends/receives/grabs/colls/prints throughout my patch with a

> texteditor that has advanced search options (e.g. the textwrangler

> 'Find all' option). In fact I am just waiting for a 'Find all' option

I'd would be already happy to have a working simple find... (I mean show 

(select) the object I am looking for in patch mode...)

For editing text I also use textwrangler, very convenient and 

Mattijs Kneppers wrote:
> I use the text representation a lot. Not to edit but to search for
> sends/receives/grabs/colls/prints throughout my patch with a
> texteditor that has advanced search options (e.g. the textwrangler
> 'Find all' option). In fact I am just waiting for a 'Find all' option
> in Max.

I'd would be already happy to have a working simple find... (I mean show 
(select) the object I am looking for in patch mode...)
For editing text I also use textwrangler, very convenient and 
recommended....

I've started generating sets of tutorials with a descriptive comment on the second line of the text file so:

This seems to work as both copy and paste and save file as... and open. However, as might be expected, it does generate an error message...

The reason is so that I can post lots of patches and read them via php - with the above I can display both the filename and the descriptive comment, making the list much more friendly. For the moment the error messages are worth it. It would be nice to have a method of commenting that didn't generate the errors, though.

This seems to work as both copy and paste and save file as... and open.  However, as might be expected, it does generate an error message...

The reason is so that I can post lots of patches and read them via php - with the above I can display both the filename and the descriptive comment, making the list much more friendly.  For the moment the error messages are worth it.  It would be nice to have a method of commenting that didn't generate the errors, though.


On 3-May-2006, at 18:53, Richard Hoadley wrote:

> The reason is so that I can post lots of patches and read them via 

> php - with the above I can display both the filename and the 

Part of the point of PHP is that you can access databases backends. 

So one alternative might be to build a simple SQL database... 

probably only needs a single table, consisting of filename and the 

offending ;-) comment. Once you're there, you might want to add some 

Having to maintain such a simple database with your patch development 

is probably no more onerous than post-processing your patchers-saved- 

as-text-with-embedded-non-syntactical-comments.

You might want to look at how the MaxObjects site works.

On 3-May-2006, at 18:53, Richard Hoadley wrote:
> The reason is so that I can post lots of patches and read them via  
> php - with the above I can display both the filename and the  
> descriptive comment

Part of the point of PHP is that you can access databases backends.  
So one alternative might be to build a simple SQL database...  
probably only needs a single table, consisting of filename and the  
offending ;-) comment. Once you're there, you might want to add some  
other stuff.

Having to maintain such a simple database with your patch development  
is probably no more onerous than post-processing your patchers-saved- 
as-text-with-embedded-non-syntactical-comments.

> The reason is so that I can post lots of patches and read them via

> php - with the above I can display both the filename and the

> descriptive comment, making the list much more friendly. For the

> moment the error messages are worth it. It would be nice to have a

> method of commenting that didn't generate the errors, though.

If you place a hidden comment together with a keyword into the patch, 

you could scan it as well. Could also be an abstraction made for that 

purpose which could print usefull information into the Max window...

Richard Hoadley wrote:
> The reason is so that I can post lots of patches and read them via
> php - with the above I can display both the filename and the
> descriptive comment, making the list much more friendly.  For the
> moment the error messages are worth it.  It would be nice to have a
> method of commenting that didn't generate the errors, though. 

If you place a hidden comment together with a keyword into the patch, 
you could scan it as well. Could also be an abstraction made for that 
purpose which could print usefull information into the Max window...

comments in patcher as text