Max/MSP: VT external object
This external for max/msp is a mix between [send]/[receive], [grab] and [value] with some extra functionality. It can be easily voiced and it even improves the communication between different devices in Max4Live.
download it here (v20120913) (currently Mac only)
- It is different than [value] because you can dynamically set the name and use the auto attribute to update other instances automatically.
- It is different than [send]/[receive] because you can turn the automatic update on and off, useful for interfaces (plus it doesn’t suffer from the thread safety bug which is still there in Max 5, and it improves communication in Max for Live).
- It is different than a [grab]/[receive] construction which you could otherwise use for a shared value because it is much simpler, plus you can get feedback where else in your patch a [vt] with the same name is used.
changelog:
v20120913:
- stability improvements for multithreaded situations
v20111001:
- improved thread safety (now using a separate mutex for every vt+voice combination)
- doubleclick on object gives clickable list of objects
- lists starting with a number are now properly handled
v20110822:
- first public version
Bravo, great objects!
In M4L they are faster than send/receive and they’re very reliable.
Also (maybe the most important feature), this is an alternative to [grab] in M4L!
looks good!
what is the thread safety bug? clearly we can rely on send and receive type objects for communication. I’ve used them in M4L, under the impression they would work well, and immediately – would you consider going into some more detail here on what the issues are? I guess local host udpsend would also be an option.
thanks,
Andrew
Thank you andrew, 2 things:
– the bug:
it has to do with rapidly setting the name of a receive in a complex max patch while overdrive is on. The crashed thread will look like this:
1 com.cycling74.MaxMSP 0x00047f52 receive_doset(receive*,symbol*) + 62
2 com.cycling74.MaxMSP 0x00033c14 defer + 110
3 com.cycling74.MaxMSP 0x00047fb2 receive_set(receive*,symbol*) + 48
We encountered this in several projects. This bug is acknowledged by cycling 74, but it will not be fixed before the release of Max 6. The VT object does not suffer from this and it ‘saved’ our current project actually.
– the timing:
using send and receive between devices and tracks in ableton will not give you a good or reliable timing. The timing is then strongly dependent on the audio buffer size. Actually the delay is rougly equivalent to the input latency in ms (so for say 64 samples this might be good enough) but also: it is not constant, sometimes the data arrives earlier.
The VT object seriously outperforms send/receive in this situation. I guess this has to do that with Live’s threading model and the way I implemented my objects. I made an example ableton song with simple test devices so that for you to show how I tested it: http://www.timorozendal.nl/files/srlatencytest.zip