cshot~

[*~ ]

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?

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.

thanks, but how would you open the left inlet untill a click came trough and then close it immediatly?

click~

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.

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.

-110

would el.mask and el.clickhold be what you mean by spike-to-state?

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:

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.

-110

.

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.

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.

lh

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~...

-110

Not very pretty or efficient but you can do it with standard objects like this...

Just found a better solution

the impulse-to-state thing:

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.

Eric

Hi,

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

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) :)

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...

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.

The dimension of my ignorance is only matched by the size of your ego, Roman! Thank you for humbling me :)

dont worry, there are some objects which also managed to hide from me for about 10 years.

Damn I've missed this forum lately ;)