< Back to IRCAM Forum

Actually an FTM question

MuBu
#1

The FTM forum seems to be offline (the link to it on the FTM page is dead), but I know many of the same people are here, so it gets posted here…

I just reopened a patch that uses quite a bit of FTM for the first time after updating to Mojave, and I’m noticing some strange behavior. It may not be connected, as I haven’t looked at it in a couple of months, but it’s the only thing on my computer that’s changed…

In a patch in Max 8, I have ~250 subpatches (mostly poly~ instances using a local variable “index”. In most (but not all!) of the poly~ instances, the variable has renamed itself with “index”+number. I see the number when the patch is locked, but they disappear when unlocked. Thus, when I’m trying to refer to it somewhere else in the patch using $index, the variable can’t be found. They are defined as local in the inspector. Pictures attached to illustrate.

If I destroy them, recreate them, and relaunch Max, they seem to stay, but it does shake one’s confidence. Has anyone had any similar issues? This is with Max 8.0.3, and FTM 2.7.0. Does anyone have any wisdom on this? Is FTM still alive?

Thanks,

\M

var_locked.jpg

#2

Hi Matt, the ftm list is here: http://lists.ircam.fr/wws/info/ftm
Under the list’s Shared Documents, you’ll find ftm-2.7.3 that fixes some stuff. Please tell us if your problems go away.
Best!

#3

Hey Diemo!

Sorry to say it’s the same problem. Lots of errors like this on load:

ftm.mess: undefined name ‘engine’ in “$engine”
ftm.mess: undefined name ‘engine’ in “($engine = $1)”
ftm.mess: undefined name ‘index’ in “($index = ($reverse [$1 0]))”
ftm.mess: undefined name ‘engine’ in “$engine”
ftm.mess: undefined name ‘engine’ in “($engine = $1)”
ftm.mess: undefined name ‘index’ in “($index = ($reverse [$1 0]))”
ftm.mess: undefined name ‘engine’ in “$engine”
ftm.mess: undefined name ‘engine’ in “($engine = $1)”

there are variables by both those names, but as before when the patch is locked, they appear as “engine23” and just ‘engine’ when unlocked.

I don’t know if this is helpful, but the really strange thing is this: these variables are inside poly~ instances which are themselves inside bpatchers. Some of these bpatchers are not showing this behavior, but most are. I even have cases with two copies of the same bpatcher, and one has this problem and another doesn’t. I have just tried deleting and replacing the funky bpatchers, but after a quit of Max, the problem returns…

Please let me know if there’s any other information I can help you with…

Cheers,

\Matty

#4

Okay, I seem to have repaired it, but it’s a bit kludgey. What seems to have happened (and as I say, I had this exact patch running with no issue for months, so it was either an incremental Max change or the Mojave update) is that I was referenceing the variables (via a loadbang) before the variable had instantiated, that’s the only thing I can come up with, although that doesn’t sound very possible. Nevertheless, I found that if I deferred the loadbang that referenced the variables (sometimes rather extremely, some subpatchers needed two deferlows) all the FTM local variables would instantiate without complaining or renaming themselves.

Is it possible that if there enough FTM variables (I’m probably talking 500-ish local variables), that patches would start loadbanging before whatever bookkeeping FTM has to do is finished? I’m no specialist, but it’s the only thing I can think of.

So I don’t think the upgrade fixed it, but I did come up with a workaround, which might be helpful for you to know about… Are you coming to Expo 74? This patch I’m having trouble with is for an installation I’m presenting there…

\Matty

#5

That’s the explaination: You must use the “execute on loadbang” option in ftm.mess and not Max’s loadbang: It fires when all the logic to get decent scoping out of Max’s “everything is global” has finished.

#6

Wow, I had no idea that functionality existed. However, if I’m passing a variable through the ftm.mess (via say patcherargs or thispoly~) to set the local variable, using that option won’t really help, will it? So if I’m initializing like this:

[thispoly~]
|
|
[($engine = $1)]

I still have to delay the message somehow, no? or is there some other trick I’ve overlooked? I imagine in the case of patcherargs, I could set it to execute at loadbang and just do this, right?

[(engine = #1)]

Thanks,

\M

\M

#7

Hi Diemo,

I have a whole package which is the 2.7.0 BETA (according to the package-info.json) but it doesn’t come from the http://ftm.ircam.fr page as it’s also mentioned in the infos! Maybe that’s why Matty wanted to know if FTM is still alive :slight_smile:

On the lists page there’s only folders of .mxo, how can I update FTM ? Overwriting the .mxo ? Is there a full—package anywhere ?

Have a nice week-end,

Cheers~

……………………jerome

#8

For whatever it’s worth, Jerome, I just replaced the externals in the 2.7.0 package and left the rest of it intact. It’s mostly helpfiles, and whatnot, so it shouldn’t make any difference…

I was concerned about the status of FTM because if you go to http://forumnet.ircam.fr/, FTM isn’t listed in the products dropdown, and if you go to community>>User Groups, the ftm group isn’t listed there either. so it looks like the only route to FTM is http://ftm.ircam.fr/

\M

#9

To answer my question about getting an ftm-friendly loadbang in a poly~ instance, I realized I can just put ‘bang’ in an ftm.mess, and set that to ‘execute on loadbang’…