Chris Gough

We are trying to port the VIZZable M4L video devices so that they are compatible within Max 7, but the first hurdle I have found is that we can't pass data other than audio or midi data by cable between M4L devices.

If the Inlet and Outlet objects worked in M4L devices then we would be able to easily pass non standard data to and from M4L devices hosted in Max 7.

I guess the only other option is to just copy and paste the devices to another max patch and have 2 copies for the two different tasks, not ideal or elegant but would work.

We are trying to port the VIZZable M4L video devices so that they are compatible within Max 7, but the first hurdle I have found is that we can't pass data other than audio or midi data by cable between M4L devices. 

live-7-feature-request-working-inlet-and-outlet-objects-in-m4l-devices-in-max-7

If that worked you would end up with 2 different versions anyway yeah? One which passed audio and MIDI as in Live, and another which passed video, which wouldn't work in Live.

I'm curious though, is there something missing in vizzie in Max 7 which motivates you to attempt this?

Hi Chris (suppose you're Chris Gough...). Doesn't your virtual routing system work anymore ?

We've been passing video around M4L devices using send and receive messages and identifying devices using the device ID value. VIZZable updated the old Vizzie devices with an all GL workflow and added some new devices. the "auto-connect" we used doesn't work when loading the M4L devices into Max 7 as live.path reports "this_device" as "ID 0", but then there is no need for the auto-connect when hosting in max 7. I guess two versions is the way forward unless I can figure out some sort of midi trick ;-)

The solution actually turned out to be creating the native max patch and hosting them in a bpatcher in a m4l device wrapper. Saves maintaining 2 versions....

Live 7 Feature Request: Working Inlet and Outlet objects in M4L Devices in Max 7.