Adam Murray

Any chance phasor~, pipe, and all those other transport-aware objects will support a @transport attribute soon? I'd like to use them with a transport other than the default one.

in-need-of-transport-attribute

Quote: stefantiedje wrote on Sun, 07 December 2008 23:14

----------------------------------------------------

Yes, but I want to be able to change the tempo. To do that I have to set up all this extra cruft to make sure I store and then retranslate the notevalue whenever the tempo changes. It's possible but I don't like it. This is handled for me when I use the default transport, so I'd like it to "just work" with a named transport too.

> But I agree, as there seems to be the translate functionality built in, 

> it could as well listen to a transport attribute as metro does for 

I have the feeling it's always been intended that these objects support named transports, but it just hasn't happened yet due to time constraints. I'm wondering if it might happen sooner rather than later?

If only a few were to be updated at first, I'd vote for line~ and phasor~. Then pipe, delay~, and delay.

Quote: stefantiedje wrote on Sun, 07 December 2008 23:14
----------------------------------------------------
>
> combine them with translate...

> But I agree, as there seems to be the translate functionality built in, 
> it could as well listen to a transport attribute as metro does for 
> example...
>

I have the feeling it's always been intended that these objects support named transports, but it just hasn't happened yet due to time constraints. I'm wondering if it might happen sooner rather than later? 

If only a few were to be updated at first, I'd vote for line~ and phasor~. Then pipe, delay~, and delay.


> Any chance phasor~, pipe, and all those other transport-aware objects will support a @transport attribute soon? I'd like to use them with a transport other than the default one.

I fully share that sentiment - pardon my language, but goddammit the 

transport system will rock when that's sorted - you will then be able to 

do all manner of trickery by dynamically switching transport affiliations.

> I have the feeling it's always been intended that these objects support named transports, but it just hasn't happened yet due to time constraints. I'm wondering if it might happen sooner rather than later? 

> If only a few were to be updated at first, I'd vote for line~ and phasor~. Then pipe, delay~, and delay.

I'd settle for phasor~ for starters - we could drive all manner of 

things from a transport-switchable phasor~.

Adam,
> Any chance phasor~, pipe, and all those other transport-aware objects will support a @transport attribute soon? I'd like to use them with a transport other than the default one.
I fully share that sentiment - pardon my language, but goddammit the 
transport system will rock when that's sorted - you will then be able to 
do all manner of trickery by dynamically switching transport affiliations.

> I have the feeling it's always been intended that these objects support named transports, but it just hasn't happened yet due to time constraints. I'm wondering if it might happen sooner rather than later? 
>
> If only a few were to be updated at first, I'd vote for line~ and phasor~. Then pipe, delay~, and delay.
>
I'd settle for phasor~ for starters - we could drive all manner of 
things from a transport-switchable phasor~.

Quote: Wetterberg wrote on Mon, 08 December 2008 02:59

---------------------------------------------------- 

> I'd settle for phasor~ for starters - we could drive all manner of 

> things from a transport-switchable phasor~.

Agreed, phasor~ should definitely be a priority.

Now I'm not sure why I asked for line~. Since you have to send a message to line~ to make it do it's thing, this is the easiest situation to set up a translate w/ a non-default @transport to convert to the correct time in milliseconds, regardless of any tempo changes that may have been happening. For phasor~ it's much more of a hassle.

Quote: Wetterberg wrote on Mon, 08 December 2008 02:59
---------------------------------------------------- 
> I'd settle for phasor~ for starters - we could drive all manner of 
> things from a transport-switchable phasor~.

Agreed, phasor~ should definitely be a priority. 

Now I'm not sure why I asked for line~. Since you have to send a message to line~ to make it do it's thing, this is the easiest situation to set up a translate w/ a non-default @transport to convert to the correct time in milliseconds, regardless of any tempo changes that may have been happening. For phasor~ it's much more of a hassle.


Any news about the opportunity to link phasor~ to a different named transport object?

Sorry to revive this old thread, but I'm concerned with this problem right now, so, does anybody know a way to link a phasor~ to a different transport than the default one ?

Currently trying to figure this one out. Really want to sync a phasor~ to a named transport. Any ideas how to work this?

in need of @transport attribute