From ftm
Jump to: navigation, search
(Older versions)
(Current version)
Line 9: Line 9:
 
Max 4.6 on Windows
 
Max 4.6 on Windows
 
* [http://ftm.ircam.fr/downloads/FTM.2.3.4.BETA-Max46.exe FTM 2.3.4.BETA binaries for Max/MSP 4.6 on Windows]
 
* [http://ftm.ircam.fr/downloads/FTM.2.3.4.BETA-Max46.exe FTM 2.3.4.BETA binaries for Max/MSP 4.6 on Windows]
 +
 +
 +
''Known issue:''
 +
 +
Attention: FTM is still not entirely thread-safe. Messages or expressions that are executed in different threads (alarm, GUI/main, UDP input, etc) and simultaneously modify FTM data structures (objects) can cause crashes. The easiest way to avoid this is to reschedule congruent accesses to FTM object into the same thread. The externals "pipe" or "ftm.schedule" (that now is thread-safe) with a 0 delay time would always output in the alarm ("high priority") thread while "defer" and "deferlow" can be used to reschedule messages in the Max main application (GUI) thread.
  
 
== Older versions ==
 
== Older versions ==

Revision as of 12:33, 30 June 2008

Current version

FTM & Co 2.3

Max 4.6 on Mac OS X

Max 4.6 on Windows


Known issue:

Attention: FTM is still not entirely thread-safe. Messages or expressions that are executed in different threads (alarm, GUI/main, UDP input, etc) and simultaneously modify FTM data structures (objects) can cause crashes. The easiest way to avoid this is to reschedule congruent accesses to FTM object into the same thread. The externals "pipe" or "ftm.schedule" (that now is thread-safe) with a 0 delay time would always output in the alarm ("high priority") thread while "defer" and "deferlow" can be used to reschedule messages in the Max main application (GUI) thread.

Older versions

Max 4.6 on Mac OS X

Max 4.5 on Mac OS X

Max 4.6 on Windows

Max 4.5 on Windows