Hello 
I am having conversion issue with Axoloti. I am trying to convert a a bool to a rising/falling bool. Seems like it is the in/outlet that does the conversion.
Does anyone know how to do the conversion from bool to rising/falling bool with code?
Thanks, Jaffa
I have a very simple one for rising here:
It sends a pulse on a rising front
community -> tiar->logic-> rising.
Local data code
bool _in=false; // the previous value of the inputK Rate code
outlet_trig = inlet_in && !_in;
_in = inlet_in;Super @SmashedTransistors
Thank I will definatly try this.... I hope it will work for rising/falling too then 
Do you mean if bool is greater than zero, then it will rise wait for a period of time then fall ?
Or do you want want one signal to rise and a different signal to fall at the same time ?
I have lots of bool variations, if I know exactly which one you are refering too, I should be able to assist.
List of some.. from a standard momentary trigger..
- Inverted momentary trigger.
- momentary to toggle on rising edge only.
- momentary to toggle on falling edge only.
- momentary either standard or inverted with held time delay to toggle or momentary a completely seperate trigger.
- two seperate triggers at the same time within an agreed time period triggering a completely seperate trigger.
- linking several of the above options from one or more triggers for even more variations, example from one momentary press and release.. momentary to toggle on rising edge only will trigger one event, then on the release momentary to toggle on falling edge only will trigger a completely seperate event.
Oh I forgot to post the picture before!
It is for a noise gate, following Sputnkis idea. Check the com.lib subpatch sptnk/effect/noise gate
I am not 100% sure about the technical names of it. But I would like to do something like on the picture. The math/>c has bool out. And the env/ahd has bool rising/falling in.
So from how I understand the pciture I would like to convert from bool to bool rinsing/falling. If possible
Just tested @SmashedTransistors suggestion for convert tol rising. THat didnt work out. Same result as when just connecting without any conversion.
The inlet do not do any conversion, they are plain boolean, the rise/trig are just annotations so the user of the object knows what to supply - the code has to do the detection itself.
look at the envelopes to see how to detect, it's fairly simple - basically you just need to track previous state.
I patched the same internally in an object and that doesnt work. It works with factory objects. The only difference there is, is that the out/inlets are not there. So it most be done by the in/outlets About conversion in general; there are several objects where conversion in basically done by the in/outlets. For example the conv/bo f ... that object only contains this code;
outlet_o= inlet_i;
No conversion done in the objects code. Therefor the comversion must be done by the in/outlets. Same with conv to b object.
I faced this issue a few times lately and most of the times I found a way to convert it with additional code.
This example is another one. Convert the output of a math/> to fractional.
Add this code to the code you want to convert; ?0x07FFFFFF:0
But I guess maybe adding code in not necessary. Maybe I can just edit the code instead
WIll take a look
trigs/rise/fall etc are not types.... so are not subject to type conversion.
types are indicated by wire colour, hence, float to int (blue to green) , and so are subject to type conversion, but trig/rise/fall are all yellow, because they are all boolean, all the same type, its just how that bool is going to be interpreted/used.
as i stated, the trig/pulse/gate/rise/fall are just annotations/information in the case of inlets they tell the user what is expected, and in the case of outlets, what the user can expect.
anyway, that's all i wanted to point out, as i don't want any one in the future reading this thread, thinking there is some hidden conversion going on, there is not.
have a great easter weekend... I'm off to enjoy the sun.
..it did some stuff like rbrt/control/t2p (toggle to pulse)
and p2t (pulse to toggle)
maybe that helps
I wonder if this has been overthought, maybe I am stating the obvious here but getting back to basics may assist here.
Bool - zero is off, one or higher is on.
Rising edge - going from zero to one.
Falling edge - going from one to zero.
The best way to detect this in code is to hold onto the current value and wait for it to change, when it changes it will be different from the previous.
Edge detection is a conditional change which you have to detect, this can be done with code or electronic circuitry, and is very fundemental in electronics in so many different forms.
As for patching, it is not something you can convert unless you have a condition to analyse for a logical outcome.
If you are converting from krate polar, off will be zero, on will be anything above zero. If you want to better define where the zero point is, you will need to use math to change the zero point of reference.
Hey Gavin
Sorry for the late reply..... Maybe have been over though... I just want to do what you see on the picture with code. The math/>c hat got a boolean output. the env/ahd has got a bool rising/falling input.... It works when connected like on the picture. But when I do the exact same with code it does not work...
I am not 100% sure about the technical terms of what I want to do. That is why I ask here. I just look at the objects, see the difference, and aknowledge that the difference, the in/out kind of must be be what make it behave different. So toubleshooting away here
I think I sought of follow what you are getting at.
As the value gets above or below a certain value, it will trigger a bool on or off depending on wether it is above or below a constant hence "math>c" ?
It will all be based on the conditions that are set againts the values for true or false output. Just keep checking the values you are using, make sure it is all giving the correct responce resulting in the required bool output.
Maybe posting the code might help.. ?
Hey @Gavin
Yeah you are right I should post the code. I though this was an easy one, so I didnt include it to start with.
I will post it later tonight
que?
the inlet/outlet type makes no difference, as i keep telling you ... try it for yourself, if you don't believe me (which you obviously don't) , take a env/d embed the object, change the inlet type to a straight bool... guess what? it still works...
the code is , as i said, in the env object...
here is a slightly modified version of env/d, the mod is to output the the trig rise as a pulse
if ((inlet_trig>0) && !ntrig) {
ntrig=1;
outlet_out = 1 << 30;
}
else {
outlet_out = 0;
if (!(inlet_trig>0)) ntrig=0;
}what you can see from this is , that its the first condition (which you will find in all over the place in factory objects) that detects the rise, basically its says. if the inlet is 'high' and the previous trig was not high, then we have a rise, the else clause deals with either a continued high, or it being low,... the condition within it, looks to reset ntrig when the inlet goes low.
the best way to understand it, is to write it down on a piece of paper and follow it thru.
doing a fall detection, is basically the same, but in reverse, spotting the inlet is low but was previously high.
Thank you for the example. I just redid the whole thing and now it freaking works.
Maybe I did make an error somewhere even though I checked it many times. Hard learning....
I apologise to all and thank you for the input again.
Local data code
bool _in=false; // the previous value of the input
K Rate codeoutlet_trig = inlet_in && !_in;
in = inletin;
Using this trigger detection code it will take 2 passes to determine if there's a rising edge at the input
3000 / 2 = 1500 hz.
This is the highest frequency a stream of triggers can have.
Thank you, I did get it working
Yeah, well I did got back and trouvleshoot it.... And it had nothing to do with the code. It had to do with the knobs used. I used 2 bipolar knobs, which didnt work, cause the envelops knobs needed one of the other knob types, I think it was lineardecay, something....