[newbie]: loadbang (or similar) on patch lock
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
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.
_M
On 26 avr. 08, at 17:28, ubi de feo wrote:
>
> 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
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
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.
Dble clic in the [loadbang] instance will trigger it too!
p
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.
_M
On 26 avr. 08, at 18:02, ubi de feo wrote:
>
> 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
thanks patrick.
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 love how active this forum is and how people reply quickly en masse.
@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).
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.
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 :)
u
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.
j
oooohhhh
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.
it's fun anyway.
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.
thanks everyone who replied
u
On 26 avr. 08, at 18:20, manuel@cycling74.com wrote:
> 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.
In the ejies, I've something called ej.lock which reports the changes.
ej
hi, emmanuel
very interesting helpers of yours.
with JS I figured out I could access
this.patcher.locked
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 :)
wow!
nevermind...
didn't dig into your code first.
you can actually create tasks?
this is cool.
I HAVE WHAT I WANTED :)
and I learned a new thing on JS in Max
this thing rocks
thank you emmanuel
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:
> you can actually create tasks?
yep, so the polling is done in the js object. I'm glad you appreciate,
I just made it for fun ;-)
ej
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.
-C
Chris Muir
cbm@well.com
http://www.xfade.com
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
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
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...
Hey! That's my niche you're talking about!
Chris Muir
cbm@well.com
http://www.xfade.com
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?
@JOHYDE put this in a js object:
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?
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!
Cheers!
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!