Forums > MaxMSP

storing deprecated code

June 13, 2006 | 11:22 pm

Hello again.

I am involved in the cleanup of a patch, and am in the process of
clearing out sections of "dead" code. I wish to get this code out of
the way of the functional patch, but keep it on hand in case of a
rollback. Moving all of the code to a subpatch accomplishes most of
this, but the code is still "active" in the patch, as it uses sends and
receives. What would be *really* nice would be if there was a way to
quarantine this code, but still keep it within the patch.

Is there a way to do this, besides renaming all of the sends and
receives (of which there are many)? To "shutdown" code, but keep it
available within your patches? A Max version of "commenting things out"?

I don’t believe so, but perhaps someone has an idea…

Thanks.


barry threw :: sound | (if you would see the stars clearly,
http://www.barrythrew.com | look hard at the surrounding darkness)
bthrew(at)gmail(dot)com | -Ooka Makoto
857-544-3967 |


June 13, 2006 | 11:40 pm


June 14, 2006 | 12:19 am

That’s what I was looking for.

Thanks.


barry threw :: sound | (if you would see the stars clearly,
http://www.barrythrew.com | look hard at the surrounding darkness)
bthrew(at)gmail(dot)com | -Ooka Makoto
857-544-3967 |


June 14, 2006 | 12:45 am

Actually, on second thought, this doesn’t work right.

But, I don’ t think there is any way to do what I want to do, so we’ll
call this a "feature request".

Making an abstraction automatically means that the dead code is stored
*somewhere else*. I want it in a subpatcher, always within that patch.

There should be a way to "comment out" Max code, so that it isn’t active.

Sometimes Max feels like a Ferrari without windshield wipers…

b


June 14, 2006 | 9:33 am

On 14 Jun 2006, at 01:45, Barry Threw wrote:

> Making an abstraction automatically means that the dead code is
> stored *somewhere else*. I want it in a subpatcher, always within
> that patch.

I don’t understand what you gain from this, except for the ability to
completely disable the code (messages, DSP, shared state, etc.). Why
do you want the dead code in the active patcher? Why not in some
other patcher (with the added feature of being able to completely
disable the latter, in case you want to copy/paste some code across)?

– N.

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


June 14, 2006 | 5:56 pm

If the deprecated code is in the active patcher then it moves with the
patcher, it is always available for rollback. You can disable
functionality, try to implement something in a new way, and then easily
revert. I’m not sure if you do much coding in a non-graphical world,
but commenting out sections isn’t just useful, its necessary during
development.

Could I copy and past the code somewhere else? Sure. But what are the
disadvantages to this? I have to have an organizational structure in
place that lets me remember where exactly the code went, and what I did
in place. *Especially* with a graphical programming language like Max,
orientation and placement is useful both pragmatically and as a mnemonic.

Is it impossible to manage deprecated code in another patcher? No.
It’s just a pain in the ass.

There are lots of features in Max that seem more superfluous than a
disable feature. I mean come on…imageburgers?

b


barry threw :: sound | (if you would see the stars clearly,
http://www.barrythrew.com | look hard at the surrounding darkness)
bthrew(at)gmail(dot)com | -Ooka Makoto
857-544-3967 |


June 14, 2006 | 6:13 pm

On 14 juin 06, at 19:56, Barry Threw wrote:

> If the deprecated code is in the active patcher then it moves with
> the patcher, it is always available for rollback. You can disable
> functionality, try to implement something in a new way, and then
> easily revert. I’m not sure if you do much coding in a non-
> graphical world, but commenting out sections isn’t just useful, its
> necessary during development.

It sounds like it’s not the job of Max. You can use CVS, subversion
or whatever to do that.

> There are lots of features in Max that seem more superfluous than a
> disable feature. I mean come on…imageburgers?

imageburner. you’re kidding? is really useful to hide max boxes and
display something else… it just depends on what you do with Max.

Best,
ej


June 14, 2006 | 6:55 pm

Quote: barry threw wrote on Wed, 14 June 2006 10:56
—————————————————-
> commenting out sections isn’t just useful, its necessary during development.

After years of working with Max and its "unique" methods, I have found that conceptualizing in more traditional ways within Max is extremely useful.

For example, I use very few sends and receives; instead, I use values to function like traditional variables. This ensures that I have the data that I want only when I want it (as opposed to whenever it is sent).

I also try to encapsulate as much as I can, with only one in and one out per patcher.

I find this much easier to debug large programs, and swap patchers/abstractions in and out.


June 14, 2006 | 7:19 pm

On 14 Jun 2006, at 18:56, Barry Threw wrote:

> I’m not sure if you do much coding in a non-graphical world, but
> commenting out sections isn’t just useful, its necessary during
> development.

But you can do that in Max by deleting a patch cord.

It sounds as if you’re after something more heavyweight – in which
case a source control system might be appropriate – but, yes, a
feature to completely disable a chunk of a patcher would be useful in
various circumstances.

– N.

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


June 14, 2006 | 8:46 pm

These are all good ideas that everyone has had.

But as for version control…I’m looking for a scalpel and not a
sledgehammer. You wouldn’t tell a C programmer that they have to use
CVS and not comments.

It’s a moot point I guess.

The code is dead. Long live the code.


barry threw :: sound | (if you would see the stars clearly,
http://www.barrythrew.com | look hard at the surrounding darkness)
bthrew(at)gmail(dot)com | -Ooka Makoto
857-544-3967 |


June 14, 2006 | 8:48 pm

> There are lots of features in Max that seem more superfluous than a
> disable feature. I mean come on…imageburgers?

very useful for windowed UI.


June 15, 2006 | 8:08 am

On 14-Jun-2006, at 22:46, Barry Threw wrote:
> You wouldn’t tell a C programmer that they have to use CVS and not
> comments.

This is true enough. However, Max isn’t C.

One of the things Max *is*, is a graphical programming language. Off
hand, I cannot think of any GPL that supports something like the
commented-out code technique familiar from text-based PLs. But I
don’t claim to know all GPLs. Can anyone reading tell how any of
LabVIEW, CAGE, Reaktor, LogoBlocks, & Co. provide for this sort of
temporary disabling of blocks of code? Do they support it at all?

FTR, the way I’ve dealt with this situation is to make a duplicate of
the patcher in Finder, tag the date onto the duplicate’s file name,
and then return to the original to boldly delete whatever it is I
might want to come back to someday. I might even split an infinitive
while I’m at it.

Maybe less fine than a scalpel but not as brutal as a sledgehammer.

– P.

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

iCE: Sequencing, Recording & |home | chez nous|
Interface Building for |bei uns | i nostri|
Max/MSP Extremely cool http://www.castine.de

http://www.dspaudio.com/


June 15, 2006 | 10:22 am

Correct me if I’m misunderstanding, but isn’t this what gate is for?
Instead of deleting patch cords (or a subpatcher) add a [gate], even
a [gate 1 1], and you can turn on/off the flow of information to that
gate. I use that to "comment out" blocks of max code. As long as
you understand the right-to-left and top-to-bottom flow of
information in Max, it’s a very useful technique.

-Evan


June 15, 2006 | 11:55 am

On 15-Jun-2006, at 12:22, evan.raskob [lists] wrote:
> Correct me if I’m misunderstanding, but isn’t this what gate is for?

This, like all the other suggestions made in this thread, are almost-
but-not-quite-exactly-the-same-thing as commenting out code. There
will be arguments for why your approach isn’t quite what someone else
wanted.

But if it works for you, great, and the more suggestions around for
temporarily disabling some processing flow, the better.

– P.

[Please cf the .sig from my previous post on this thread if you need it]


June 15, 2006 | 6:49 pm

All of these things work with either small or mid sized patches just
fine. However, once your scale increases, and your development time
speeds up, these solutions just aren’t adequate.

What if you are brought in to work on another patch? What then?

Like all of these suggestions, they seem like workarounds to gain a
functionality that is needed, but not directly supported in the most
intuitive and least time consuming way.

b


barry threw :: sound | (if you would see the stars clearly,
http://www.barrythrew.com | look hard at the surrounding darkness)
bthrew(at)gmail(dot)com | -Ooka Makoto
857-544-3967 |


June 15, 2006 | 7:06 pm

so the enable message doesnt work for what you are trying to do?
i checked out some of my pre-subpatch programs, it seems to work ok
for me, but i didnt use send/recieve objects…

what would dafna do?


June 15, 2006 | 7:24 pm

Nah. It doesn’t stop sends and receives.

I guess to clarify, what I need is not to disable blocks of code
(because everyone is right when they say "just delete the patch cord")
but a way to disable sends and receives.

b


barry threw :: sound | (if you would see the stars clearly,
http://www.barrythrew.com | look hard at the surrounding darkness)
bthrew(at)gmail(dot)com | -Ooka Makoto
857-544-3967 |


June 15, 2006 | 7:54 pm

ok. now thats a different issue. solution… dont use sends and
receives… ;)

maybe make a special subpatch called [send_stuff] and another subpatch
called [recieve stuff]. design your on/off routine in there and make
them remotely assignable. then just paste-replace/find-replace these
subpatches over all your old send receive ojbects.

or brush up on scripting.


June 15, 2006 | 8:26 pm

Good idea. I might actually start doing that in some of my patches.

However it is:
a) slower and less intuitive to disable
b) i don’t want to do this for the thousand some odd sends and receives
i have scattered around hundreds of windows.
c) it requires more machinery throughout the patch that i could do without
d) again, it is a hack to create useful functionality that should be
natively supported in the development environment

It is, however, something I hadn’t really thought of…Thanks for that.
There have been alot of great ideas…

b


barry threw :: sound | (if you would see the stars clearly,
http://www.barrythrew.com | look hard at the surrounding darkness)
bthrew(at)gmail(dot)com | -Ooka Makoto
857-544-3967 |


June 15, 2006 | 8:47 pm

sounds like you are narrowing in on a feature request.
how are you thinking this could be made to work intuitively at the
environment level?

were you thinking of highlighting a section of code or subpatch and
then clicking an edit menu and selecting (comment in/out) or
(disable/enable), and then the selected code would get all pastel and
grey and would not be an active part of the patch until you brought it
back to life?

maybe it would work like hide/show. you can see the code its there,
connected and all, but then when you lock the patch it could become
inactive.


June 15, 2006 | 9:18 pm

That’s exactly what I want.


barry threw :: sound | (if you would see the stars clearly,
http://www.barrythrew.com | look hard at the surrounding darkness)
bthrew(at)gmail(dot)com | -Ooka Makoto
857-544-3967 |


June 17, 2006 | 4:30 pm


June 17, 2006 | 6:42 pm

Accept that it makes the code unreadable.

The point is to be able to quickly glance at old code in line in its
original context.


barry threw :: sound | (if you would see the stars clearly,
http://www.barrythrew.com | look hard at the surrounding darkness)
bthrew(at)gmail(dot)com | -Ooka Makoto
857-544-3967 |


June 18, 2006 | 10:18 am

On 17 Jun 2006, at 17:30, Stefan Tiedje wrote:

> If you cut the part you want to disable, it will be represented as
> text in the copy buffer. Then just copy it as it is into a comment
> box and voila its disabled.

I would check that it doesn’t screw up "$", "#", commas and
backslashes…

– N.

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


Viewing 24 posts - 1 through 24 (of 24 total)