Logical detection of signal or float


    Oct 07 2006 | 5:17 pm
    Evidently externals can be built to accept either a signal or a float, and consequently they must be able to detect which type of object is connected to an inlet.
    Can I design a patcher/abstraction that can accept either a float or a signal at a single inlet? I've been trying to figure out how to do this, but every "solution" has some sort of error out to the Max window, even if it's non-threatening. Is there a "type" object or external that could aid in routing signals through one chain and floats through another? Maybe I'm overlooking something obvious.
    -- Paul
    -- ----- |(*,+,#,=)(#,=,*,+)(=,#,+,*)(+,*,=,#)| -----

    • Oct 07 2006 | 5:29 pm
      ej.route.js or tap.typecheck~ externals can do that...? maybe I didn't understand the question....
    • Oct 07 2006 | 5:30 pm
    • Oct 07 2006 | 6:50 pm
      > I think few people made a js object for this. For sure, ej made one > called "ej.route". Find it here : > > http://www.e--j.com/sphpblog/
      Thanks Guys... don't also forget there's always a signal message, so route works also. ej.route.js uses the same principe.
      ej
    • Oct 07 2006 | 9:03 pm
      Aha! I knew there had to be some built-in method I was overlooking, Having used route for ints and floats, it should have ocurred to me that signal might be a type. And I do have taptools also.
      thanks all,
      -- Paul
      On 10/7/06, Emmanuel Jourdan wrote: > > I think few people made a js object for this. For sure, ej made one > > called "ej.route". Find it here : > > > > http://www.e--j.com/sphpblog/ > > Thanks Guys... don't also forget there's always a signal message, so route > works also. ej.route.js uses the same principe. > > ej > > #P window setfont "Sans Serif" 9.; > #P number 549 113 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0; > #P number 544 195 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0; > #P user scope~ 435 302 565 432 256 3 128 -1. 1. 0 0. 0 0. 102 255 51 135 > 135 135 0; > #P window linecount 1; > #P newex 435 42 61 196617 cycle~ 440; > #P newex 435 162 113 196617 substitute signal signal; > #P message 203 184 36 196617 signal; > #P user ezdac~ 294 160 338 193 0; > #P user scope~ 203 303 333 433 256 3 128 -1. 1. 0 0. 0 0. 102 255 51 135 > 135 135 0; > #P newex 203 43 61 196617 cycle~ 440; > #P number 261 123 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0; > #P number 256 205 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0; > #P newex 203 163 63 196617 route signal; > #P connect 7 1 10 0; > #P connect 11 0 7 0; > #P connect 7 0 9 0; > #P connect 8 0 7 0; > #P connect 6 0 4 0; > #P connect 0 0 6 0; > #P connect 3 0 0 0; > #P connect 0 1 1 0; > #P connect 2 0 0 0; > #P window clipboard copycount 12; > >
      -- ----- |(*,+,#,=)(#,=,*,+)(=,#,+,*)(+,*,=,#)| -----
    • Oct 08 2006 | 6:49 am
    • Oct 09 2006 | 6:03 am
    • Oct 09 2006 | 6:59 am
      On 9 oct. 06, at 08:03, Stefan Tiedje wrote:
      > This would explain something about the internal difference between > scheduler and audio patch chords...
      I'm not sure what you mean here.
      > And which is more effective? the messagebox or trigger, or the > right outlet?
      I quite sure trigger is faster, but it's just done when the dsp is turned on.
      > Whenever audio is switched on, Max will run along all signal patch > chords and send one message "signal" together with the info where > it comes from (but not within that signal message otherwise a [t > signal] wouldn't work) to create a realtionship between connected > objects. That would mean these constructions create a kind of > hidden direct connection between the objects. The signal isn't > actually running through the visible patch chord. > That would also explain why send/receive (without ~) work, and why > they require to restart audio manually, to make them work (scripted > audio s/r connections usually don't work if I don't restart audio)
      You're theory is correct!
      ej
    • Oct 09 2006 | 2:42 pm
    • Oct 10 2006 | 8:55 am
      > Can I design a patcher/abstraction that can accept either a > float or a > signal at a single inlet?
      for abstractions which you will use not on a daily basis you could create your abstractions as [poly~]s.
      poly~ uses exclusively [in~] and [in] type of inlets instead of those graphic boxes - when there is an [in~ 3] object in a poly, but no [in 3], the signal inlet will also take (and output inside the abstraction) a message in addition to the signal - depending on where you connect it to.
      >Is there a "type" object or > external that could aid in routing signals through one chain >and > floats through another? Maybe I'm overlooking something >obvious. > > -- Paul
      you can use [route int float symbol bang] to "sort" types behind an inlet, the same works with the [select] object.
      then an inlet in your abstraction will accept "brgb" as well as "3.5741" and know what to do with the input.
      -110