twodotone

being at Max for just a week, there's plenty of things I don't understand, but I'm getting there.

what I need to figure out is if there's a way to trigger an object on patch lock.

loadbang is triggered at patch load, but when I switch between unlocked and locked there's no way to re-initialize my stuff.

I'm a programmer, hence it's very hard sometimes to figure out things that are too visual.

newbie-loadbang-or-similar-on-patch-lock

A practical way of re-initializing a whole patch, is to have a 

thispatcher object instanciated in the patcher.

Then, if you send it a [loadbang] message, it will re-fire all 

loadbangs in your patcher and in its subpatchers.

If you only want to initialize what's in a specific subpatcher, use 

On 26 avr. 08, at 17:28, ubi de feo wrote:

> being at Max for just a week, there's plenty of things I don't 

> what I need to figure out is if there's a way to trigger an object 

> loadbang is triggered at patch load, but when I switch between 

> unlocked and locked there's no way to re-initialize my stuff.

> I'm a programmer, hence it's very hard sometimes to figure out 

A practical way of re-initializing a whole patch, is to have a  
thispatcher object instanciated in the patcher.
Then, if you send it a [loadbang] message, it will re-fire all  
loadbangs in your patcher and in its subpatchers.
If you only want to initialize what's in a specific subpatcher, use  
thispatcher at subpatcher level.

>
> hi, everyone
>
> being at Max for just a week, there's plenty of things I don't  
> understand, but I'm getting there.
>
> what I need to figure out is if there's a way to trigger an object  
> on patch lock.
>
> loadbang is triggered at patch load, but when I switch between  
> unlocked and locked there's no way to re-initialize my stuff.
>
> am I missing some secret object?
>
> I'm a programmer, hence it's very hard sometimes to figure out  
> things that are too visual.
>
> I'm loving it, though
>
> ubi


thanks for your tip (it'll be useful one day),

but I probably did not explain myself clearly.

what I need to do is "execute" something every time I lock the patch, not just when I "load".

loadbang only happens when you load the patch.

while I work and test the app, I want the event to be fired every time I lock my patch, without the need to manually trigger anything.

hey manuel
thanks for your tip (it'll be useful one day),
but I probably did not explain myself clearly.

On 26-avr.-08, at 17:28, ubi de feo wrote:

Dble clic in the [loadbang] instance will trigger it too!

On 26-avr.-08, at 17:28, ubi de feo wrote:
>

> loadbang is triggered at patch load, but when I switch between 
> unlocked and locked there's no way to re-initialize my stuff.

Afaik, it's not possible with classical Max methods.

Maybe the Javascript freaks around here will bring the light.

On 26 avr. 08, at 18:02, ubi de feo wrote:

> thanks for your tip (it'll be useful one day),

> but I probably did not explain myself clearly.

> what I need to do is "execute" something every time I lock the 

> loadbang only happens when you load the patch.

> while I work and test the app, I want the event to be fired every 

> time I lock my patch, without the need to manually trigger anything.

Aha - I suspected something like this.
Afaik, it's not possible with classical Max methods.
Maybe the Javascript freaks around here will bring the light.

>
> hey manuel
> thanks for your tip (it'll be useful one day),
> but I probably did not explain myself clearly.
>
> what I need to do is "execute" something every time I lock the  
> patch, not just when I "load".
>
> loadbang only happens when you load the patch.
>
> while I work and test the app, I want the event to be fired every  
> time I lock my patch, without the need to manually trigger anything.
>
> is there a way?
>
> u


still there's no way to have an event fired when you lock a patch?

found out that.
still there's no way to have an event fired when you lock a patch?

i would map a key to fire a bang to a loadbang connected to a thispatcher. something like !, probably. so- apple-e to lock patch, shift-1 to init it. it's a hack, but maybe it approaches the convenience you're looking for.

i would map a key to fire a bang to a loadbang connected to a thispatcher.  something like !, probably.  so- apple-e to lock patch, shift-1 to init it.  it's a hack, but maybe it approaches the convenience you're looking for.


I love how active this forum is and how people reply quickly en masse.

mapping a key might be a good way not to click,

but it doesn't address my need (which is a quite OC one).

I'm trying to "initialize" values and objects every time I lock the patch, WITHOUT having to click, press, drag or "interact" with the patch in any way.

but the main question here is how to execute a task that is easily achieved in any language at runtime :)

@joshua:
mapping a key might be a good way not to click,
but it doesn't address my need (which is a quite OC one).

let's say I'm being lazy,
but the main question here is how to execute a task that is easily achieved in any language at runtime :)

actually, this is not quite the same as initialize-on-run-after-compile of every other language.

the max scheduler is always running, unless it's forcibly stopped or there's a stack overflow. this is a substantial paradigm difference between working in max and working in non-visual-dataflow languages.

most max programmers almost never move out of edit mode. when we want to simulate clicks in locked mode, we merely hold down command (or control) when we click a UI element. there's really no need to constantly switch back and forth from edit-to-lock unless you're working hard on finishing the look of a patch.

keep working in edit mode, lock your loadbangs to !, and you should find that the different paradigm can be quite rewarding.

the max scheduler is always running, unless it's forcibly stopped or there's a stack overflow.  this is a substantial paradigm difference between working in max and working in non-visual-dataflow languages.

most max programmers almost never move out of edit mode.  when we want to simulate clicks in locked mode, we merely hold down command (or control) when we click a UI element.  there's really no need to constantly switch back and forth from edit-to-lock unless you're working hard on finishing the look of a patch.

I noticed that accidentally clicking with command pressed caused the UI objects to react, but never realized that the whole flow was triggered.

I played a bit with my patch and it worked in edit mode.

I guess I really have to spend more time on learning.

you all can imagine how hard it can be for a code writer to approach this new world.

on the bright side, I think the debugger is really amazing.

this patching thing rocks, and with the use of javascript I can achieve a lot.

I guess I really have to spend more time on learning.
it's fun anyway.

On 26 avr. 08, at 18:20, manuel@cycling74.com wrote:

> Afaik, it's not possible with classical Max methods.

> Maybe the Javascript freaks around here will bring the light.

In the ejies, I've something called ej.lock which reports the changes.

> Aha - I suspected something like this.
> Afaik, it's not possible with classical Max methods.
> Maybe the Javascript freaks around here will bring the light.

as I said, more than polling for it, I would have liked an event fired kinda like it happens with loadbang on load.

JS proves to be very useful for very basic tasks that are not covered (at least I couldn't find any trace of them) like "for" loops.

I've never been so happy about a forum like this time :)

very interesting helpers of yours.
with JS I figured out I could access

I've never been so happy about a forum like this time :)


nevermind...
didn't dig into your code first.

and I learned a new thing on JS in Max
this thing rocks

On Apr 26, 2008, at 10:26 AM, ubi de feo wrote:

> you all can imagine how hard it can be for a code writer to approach 

Sometimes I think it's easier for a digital hardware guy, than a 

software person, to come to terms with the Max world.

On Apr 26, 2008, at 10:26 AM, ubi de feo wrote:
> you all can imagine how hard it can be for a code writer to approach  
> this new world.

Sometimes I think it's easier for a digital hardware guy, than a  
software person, to come to terms with the Max world.

Chris Muir
cbm@well.com	
http://www.xfade.com

On 26 avr. 08, at 20:28, ubi de feo wrote:

yep, so the polling is done in the js object. I'm glad you appreciate, 

yep, so the polling is done in the js object. I'm glad you appreciate,  
I just made it for fun ;-)

On Apr 26, 2008, at 11:24 AM, ubi de feo wrote:

> JS proves to be very useful for very basic tasks that are not 

> covered (at least I couldn't find any trace of them) like "for" loops.

Things that you would use "for" loops for in a traditional language, 

are generally dealt with using Counter or Uzi, in Max. It takes some 

paradigm shifting, and you may always be more comfortable using 

something like mxj to do this sort of stuff in Max.

On Apr 26, 2008, at 11:24 AM, ubi de feo wrote:
> JS proves to be very useful for very basic tasks that are not  
> covered (at least I couldn't find any trace of them) like "for" loops.

Things that you would use "for" loops for in a traditional language,  
are generally dealt with using Counter or Uzi, in Max. It takes some  
paradigm shifting, and you may always be more comfortable using  
something like mxj to do this sort of stuff in Max.

> Sometimes I think it's easier for a digital hardware guy, than a 

> software person, to come to terms with the Max world.

And even easier for an analog hardware guy. Max was easy to grab for 

those who knew an analog modular synth. In the beginning, I explained 

what was Max about, with that model. But these survive only in a small 

Chris Muir schrieb:
> Sometimes I think it's easier for a digital hardware guy, than a 
> software person, to come to terms with the Max world.

And even easier for an analog hardware guy. Max was easy to grab for 
those who knew an analog modular synth. In the beginning, I explained 
what was Max about, with that model. But these survive only in a small 
technoid niche nowadays...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com

On Apr 26, 2008, at 9:59 PM, Stefan Tiedje wrote:

>> Sometimes I think it's easier for a digital hardware guy, than a 

>> software person, to come to terms with the Max world.

> And even easier for an analog hardware guy. Max was easy to grab for 

> those who knew an analog modular synth. In the beginning, I 

> explained what was Max about, with that model. But these survive 

> only in a small technoid niche nowadays...

Hey! That's my niche you're talking about!

On Apr 26, 2008, at 9:59 PM, Stefan Tiedje wrote:
> Chris Muir schrieb:
>> Sometimes I think it's easier for a digital hardware guy, than a  
>> software person, to come to terms with the Max world.
>
> And even easier for an analog hardware guy. Max was easy to grab for  
> those who knew an analog modular synth. In the beginning, I  
> explained what was Max about, with that model. But these survive  
> only in a small technoid niche nowadays...

I'm looking for a way to know whether a patch is locked or not. ej.lock doesn't seem to be in the package any more - am I right? Anyone got another way to do this?

    actual_state = this.patcher.getattr("locked");

var polling = new Task(state);
var actual_state;

function state() {
	actual_state = this.patcher.getattr("locked");
	outlet(0, actual_state);
}

function loadbang() {
	    polling.interval = 100;
	    polling.repeat();
}

@2K - thanks so much, that's really helpful!

I got it to work, so these aren't pressing questions, but in case it's useful for anyone else (and for learning purposes, to see if I got it right - I don't know javascript at all).

By a process of elimination, I worked out that I needed to send the js object messages - 'state' to get it to report the locked status, and/or 'loadbang' to start it polling (wasn't sure if I needed both, but it works, anyway). Is this what you'd expect?

By a process of elimination, I worked out that I needed to send the js object messages - 'state' to get it to report the locked status, and/or 'loadbang' to start it polling (wasn't sure if I needed both, but it works, anyway). Is this what you'd expect?

Thanks again.

@JOHYDE the code I sent automatically start reporting the locked status every 100ms when you open the patch (the loadbang function works exactly like loadbang object). If you don't want that just erase that part of the code and send the message "state" to the js object to report the status whenever you want!

@JOHYDE the code I sent automatically start reporting the locked status every 100ms when you open the patch (the loadbang function works exactly like loadbang object).  If you don't want that just erase  that part of the code and send the message "state" to the js object to report the status whenever you want!

Ah, of course - even though I don't know js, I was just being stupid there. I just pasted that in to an open patch, so of course I didn't get a loadbang. As I say, I got it to work by adding those messages anyway, and now I reopen the patch it works of course without that. So all good!

[newbie]: loadbang (or similar) on patch lock