[PD-dev] clone doesn't take vis message on left inlet when abstraction has signal for left inlet

[Alex]

Either way, isn't [clone] a built in object so can't it take messages _and_
signals on its left inlet like [dac]? I guess maybe it sets up its inlets
to be the same as the abstraction which doesn't allow for that.. [haven't
looked at the guts].

On Thu, Jun 23, 2016 at 9:52 AM, Miller Puckette <msp at ucsd.edu> wrote:

> Good idea ... I have to think about whether this is possible to do.  If
> I could ake inlets that take both control and signal, then I could easily
> fix clone~ to take control messages like "vis" from inlets of either type.
>
> Also that might be the way for me to fix a long-standing bug - float
> messages
> to signal subpatch inlets don't work.
>
> cheers
> Miller
>
> On Thu, Jun 23, 2016 at 09:42:18AM -0700, Alex wrote:
> > I'm on pd-0.47-1 binary downloaded from UCSD [mac 64-bit].
> >
> > I've created a clone of an abstraction that has the left inlet as a
> signal
> > inlet.. from the docs I'd expect I can send a |vis 5 1( message to that
> > inlet and display the patch but I can't. If I create another inlet, to
> the
> > right of that inlet, which is a control inlet, I can send the vis message
> > to that and my instance does pop up but it does seem to me that the |vis(
> > message should always go into the left inlet to keep things consistent?
> >
> > I attached an example, leftsig_test.pd is the patch to open.
> >
> > BTW, this clone stuff is really making me wish we could have abstractions
> > that take both a signal and control info on a single inlet [like dac and
> > some other tilde objects].. I've created a wrapper around clone to play
> > with cascading abstractions and it would be nice if I could have my
> wrapper
> > operate the same as I'm assuming clone should? I know there was
> discussion
> > before.. maybe [inlet~] could actually have 2 outlets, a signal outlet
> and
> > a control outlet?
> >
> > -Alex
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20160623/77a90509/attachment-0001.html>