woyteg

Again a feature request, and I'd like to add some things to this one.

Feature request: In other programming langueges it is possible to "comment out" regions of text. The typical "//" or whatever depending on language at the beginning of a line.

Maybe for max this would rather mean to deactivate objects.

I know that many objects don't consume resources if not processing, but sometimes it can be helpful to really render an object a mere comment(there are various reasons for that I think). Ideally, keeping its connections.

So that's the feature request. Maybe there already is something like that, if so, please let me know.(I partly know the debugger but as far as I know this isn't really in there)

I'd like to put this feature request in context to at least two other requests:

The one I have been suggesting at least two times here about keyboard patching.

https://cycling74.com/forums/key-commands-for-patching/

https://cycling74.com/forums/patch-hierarchy-viewtree/

I think all this stuff is along the lines of typical IDE/laguage features and would be really nice. As I said before(in other posts) it would make max prgramming and large scale projects with max a bit faster and more professional.

Hello!
Again a feature request, and I'd like to add some things to this one.

Feature request: In other programming langueges it is possible to "comment out" regions of text. The typical "//" or whatever depending on language at the beginning of a line.
Maybe for max this would rather mean to deactivate objects.
I know that many objects don't consume resources if not processing, but sometimes it can be helpful to really render an object a mere comment(there are various reasons for that I think). Ideally, keeping its connections.

I'd like to put this feature request in context to at least two other requests:
The one I have been suggesting at least two times here about keyboard patching.
https://cycling74.com/forums/key-commands-for-patching/

And the one about patch hierarchy:
https://cycling74.com/forums/patch-hierarchy-viewtree/

I think all this stuff is along the lines of typical IDE/laguage features and would be really nice. As I said before(in other posts) it would make max prgramming and large scale projects with max a bit faster and more professional.
Cheers!


feature-request-comment-out

If may I add something here; I think the feature requests all share that they are quite fundamental things very common to other text based languages that it really seems that in inventing a really great new approach to programming some things have been dropped that are the basics of a usual text based language. Isn't it surprising that we can't few the patcher hierarchy for example? Isn't it surprising that we don't have a whole lot of syntax highlighting?(I didn't think about this a whole lot.. maybe (more) syntax highlighting in a max patch might be interesting, I don't know)

Most objects in max can be disabled by sending the message "enable 0"

Connecting this to a send and receive object allows a whole group to be disabled at once.

Most objects in max can be disabled by sending the message "enable 0"
Connecting this to a send and receive object allows a whole group to be disabled at once.


The "enable" message only relates to DSP objects I think!

I don't know which or how many objects have an enable attribute but some don't. eg. [receive]

in the special case of receive of course there are workarounds. But then if we take the enable paramter as the "comment out" function maybe I am missing the "syntax highlighting" there.

commenting out portions of code is a really handy thing. also for communicating in collaborations.

I don't know which or how many objects have an enable attribute but some don't. eg. [receive]
in the special case of receive of course there are workarounds. But then if we take the enable paramter as the "comment out" function maybe I am missing the "syntax highlighting" there.
You know what I mean?

commenting out portions of code is a really handy thing. also for communicating in collaborations.


When you say "syntax highlighting" how would you see this translating to objects in a max patch?

:) the idea of max syntax highlighting is rather a byproduct of this posting. To be honest, I don't know I think there are many things one could think about. But I just mentioned it again since it would be nice to have really disabled portions of a patch greyed out or somethying, as some IDEs give comments a different color which is kind of syntax highlighting.

Another one.. any of you max people are giving send and receive pairs the same colour? Wouldn't that be some kind of syntax highlighting analogon? That could be handled automatically maybe. Again I don't miss this particular example very much (if at all I do that via shortcut anyway). just a thought and meant as a step approaching the analogy.

you can disable patch cords, which is the equivalent of commenting out, ie

option-drag over the patch cords and go to debug->disable patch cords-- it might be nice if the attached objects maybe greyed-out when their input cords are disabled...?

It would be convenient at times if you could specify default colours for different objects, ie s and r could be blue; int, f, brown; *, +, -, / could be grey etc-- that would make 'reading' an extensive patch easier.

Even the patch cords could have default colours, ie if an output sends lists the patch cord from that could be one colour; if it's attached to an output that sends floats, or bangs or whatever, that could automatically change to another colour-- could all be user-defined of course. Just an extension of how the msp and jitter patch cords work.

It would be convenient at times if you could specify default colours for different objects, ie s and r could be blue; int, f, brown; *, +, -, / could be grey etc-- that would  make 'reading' an extensive patch easier.

Even the patch cords could have default colours, ie if an output sends lists the patch cord from that could be one colour; if it's attached to an output that sends floats, or bangs or whatever, that could automatically change to another colour-- could all be user-defined of course. Just an extension of how the msp and jitter patch cords work.


Nice one Floating Point, learnt another essential thing today !

Is disabling patchcords a Max6 thing? I can't see it in the Max5 debug menu but maybe I'm doing something wrong.

Here's a quick little javascript and test patch that will grey out object boxes and re-route connections. Select the objects you want to "comment out" plus the object immediately before and after them using the mouse. Then bang the [js] object, in this case you can just use the space bar. After this you can use the G and H keys (short for "go" and "halt", possibly) to remove the selected objects temporarily from the patch structure or add them back in. It also changes the background colour for visual feedback.

It's far from perfect but it's one way to achieve some of what you were looking for. The [js] code is in the [patcher] object at the bottom.

@floating point, yes I know about disabling patchcords, but I guess you see that it is not the same as disabling an object. Think of MSP objects or take [serial] for example. I can disable all patchcords around it, if it is still connected I have to do something about it before connecting to that device with other software (eg. arduino)

A combination of disabling objects disabling patchcords would maybe get one there. But what about abstractions that shouldn't be loaded at all maybe.

If you comment out a reagion in another language yo can be sure it simply has *nothing* to do with your program. In max, this is more work and one has to be careful applying different strategies(disabling patchcords, muting polys~, disabling objects, turning off various gates maybe etc.)

I don't want to be stubborn here, I just hope you see the quite simple idea here, it's not about the fact that one can find workarounds in any situation but about this very basic function. I am again surprised that noone else sees it that way.

@luke yes I think disabling patchcords is max 6. The debugger has a lot more functionality since version 6, but to be honest I don't use it a lot. It is very handy if you try to teach the flow of messages though. Thanks for your script! This is quite near!

@floating point, yes I know about disabling patchcords, but I guess you see that it is not the same as disabling an object. Think of MSP objects or take [serial] for example. I can disable all patchcords around it, if it is still connected I have to do something about it before connecting to that device with other software (eg. arduino)
A combination of disabling objects disabling patchcords would maybe get one there. But what about abstractions that shouldn't be loaded at all maybe. 

I don't want to be stubborn here, I just hope you see the quite simple idea here, it's not about the fact that one can find workarounds in any situation but about this very basic function. I am again surprised that noone else sees it that way. 

@luke yes I think disabling patchcords is max 6. The debugger has a lot more functionality since version 6, but to be honest I don't use it a lot. It is very handy if you try to teach the flow of messages though. Thanks for your script! This is quite near!


totally agree with you woyteg-- it's just that i use the disable patch cord feature quite a bit when debugging, trying out stuff etc, so it's worth noting at least

I agree - a "disable objects" command like this would be great to have.

Also - "disable patchcords" does not seem to put the red x on the patch cord until the patchcord is redrawn by hovering over deselecting it. That's a graphical glitch could be really stand to be improved. For instance, I mapped the shortcut Cmd-Ctrl-E to this extremely helpful menu item, and therefore would like to see feedback immediately as to whether I actually successfully pressed that complex shortcut.

[feature request] Comment out