is there a way to make a signal based onebang?

    Jul 12 2009 | 3:28 pm
    is there a way (or maybe a free external) to make something wich works like the onebang object wich accepts and outputs signals (preferably clicks)?

    • Jul 14 2009 | 7:36 am
    • Jul 14 2009 | 7:55 am
      [*~ ]
    • Jul 14 2009 | 9:55 am
      thanks, i'll have a look at cshot~Roman Thilenius wrote on Tue, 14 July 2009 09:55 [*~ ]
      how would you use that to make something similar to the onebang object?
    • Jul 14 2009 | 10:13 am
      if you send a click of 1.0 into the right inlet of a [*~ ] it passes one sample only.
      this way you can, for example, read out a certain sample value of a given sample (in conjunction with count~ and maximum) or seperate a certain sample from the rest.
    • Jul 14 2009 | 11:10 am
      thanks, but how would you open the left inlet untill a click came trough and then close it immediatly?
    • Jul 14 2009 | 1:43 pm
    • Jul 14 2009 | 1:57 pm
      i dnon't get it, i want it to work like the onebang object. when you send a click~ in the right inlet, the left inlet should stay open until a click~ comes trough then immediatly closes for other click~'s into the left inlet.
    • Jul 14 2009 | 4:34 pm
      i think i get you now, but i must say "dont have too much hope."
      what you are trying to do - using clicks as triggers in MSP - is an attempt to build logic on the signal layer.
      this is in many cases simply impossible: as soon as one part of such a network works, you will always come to another point where you again need a possibility of triggering a 0 to 1 transition (the state) by a click (the "bang").
      the only method i can think of is using a special object for that purpose, which is able to do this spike-to-state conversion. i dont know one, but maybe there is one.
    • Jul 14 2009 | 5:01 pm
      would el.mask and el.clickhold be what you mean by spike-to-state?
    • Jul 14 2009 | 7:31 pm
      You could use edge~ to convert the clicks into bangs, then just use it with a regular onebang. The bangs that are output by the onebang can then be used to trigger click~ objects, envelopes, or whatever you want. Example:
    • Jul 14 2009 | 8:54 pm
      Stephen Lee wrote on Tue, 14 July 2009 21:31You could use edge~ to convert the clicks into bangs, then just use it with a regular onebang.
      i think he wants it to output signals not bangs.
      just like [110.b1b0] but all-signal.
      which i think is not possible with the standard objects, but go and try it if someone thinks he knows how.
    • Jul 14 2009 | 9:42 pm
      Roman Thilenius wrote on Tue, 14 July 2009 16:54 i think he wants it to output signals not bangs.
      The bangs can be converted to signals using click~. If he needs it to be sample-accurate, then that's another story, but it seems like that could be done by using several signal comparison objects.
    • Jul 14 2009 | 10:00 pm
      How are you generating these clicks? If you gave us some sort of idea of what you're trying to do with such an object then maybe we could be of more help.
    • Jul 15 2009 | 12:48 pm
      btw such things (signal to signal-generation) need a lot of CPU. you can see what i mean when you compare the CPU requirement for multiple instances of [zerox~] against objects like [phasor~ ].
      [zerox~], which does more or less the opposite of what has ben asked for here, needs more than tapin~/tapout~...
    • Jul 15 2009 | 1:30 pm
      Not very pretty or efficient but you can do it with standard objects like this...
    • Jul 15 2009 | 2:08 pm
      Just found a better solution
    • Jul 15 2009 | 5:15 pm
      the impulse-to-state thing:
    • Jul 15 2009 | 7:11 pm
      Roman Thilenius wrote on Wed, 15 July 2009 13:48
      btw such things (signal to signal-generation) need a lot of CPU.
      In my experience, not necessarily. While processing signal clicks is more CPU intensive than processing bangs, it is not that expensive. For example, a samm~ object with 30 click outlets draws no more than 1% of the CPU on a 2.4 GHz Mac.
      The native MSP solution probably needs a few more objects to implement the same sample-accurate logic, so that might be more CPU intensive than my approach.
    • Apr 04 2016 | 8:19 pm
      i know its an old post by now, but heres an example. Its worth noting that this kind of logic is alot easier to do in gen~ these days, because of the 1 sample delay/history possibilities.
      Hope it makes sense
      - Gus
    • Apr 05 2016 | 1:33 am
      This is probably the simplest way to do it(after C74 introduced gen~ i notice they also added a '+=~' object for regular msp :D). [+=~] -> [==~ 0.] Check it out:
      Oh, but now i see everyone's examples create a signal click, so i see what you're going for... ooops, well, still, i bet we could trim these solutions down with something from this, in case it helps(i been using +=~ for too many things lately, sorry) :)
    • Apr 06 2016 | 1:39 am
      hey it is so great that you finally found [+=~], an object which has been added only very recently with Max/MSP v. 3.x for MacOS 8.
      but i think the date of your last post is wrong, it says 2016...
    • Apr 06 2016 | 2:00 am
      btw, the accumulators are another great example where you can see that it can become impossible to compare a signal object with a message object, not to speak of replacing the one with the other.
    • Apr 06 2016 | 5:03 pm
      The dimension of my ignorance is only matched by the size of your ego, Roman! Thank you for humbling me :)
    • Apr 07 2016 | 4:15 am
      dont worry, there are some objects which also managed to hide from me for about 10 years.
    • Apr 07 2016 | 11:00 pm
      Damn I've missed this forum lately ;)