Hi,
I have this book called 'Electronic Music and Sound Design' from Alessandro Cipriani which is very insightful to learn from. One of the first things to make, is a bit crusher. All the examples are made in MAX MSP.
There's this one object using the ! to shorten an otherwise lengthier patch. Does somebody know how to patch the equivalent in Axoloti? I'm learning the lingo step by step..
X
It’s actually the trigger bang float object in particular i don’t know how to Translate
For a trigger bang float, all it does is create a specific order of how the outputs of the object is processed. If Max works the same as Pure Data, which I am pretty sure it does, the order of processed output is right to left. The data will be processed in this order:
1. Float output.
2. Bang output.
What happens on the right side of the image you posted, where you are using the trigger bang float object, first you set the incoming value to the float output, and then you trigger the "1" value from the bang output, to get the result.
The reason for having to to this in Pure Data and Max is because objects has hot and cold inlets. In control rate objects, like the division object you are using, the right inlet is COLD inlet, which means its not actually processed before you do something to the left inlet. The right value is stored until a value is send to the left inlet and then you get the result.
So you always have to set the right inlet first and then send value to the left input and that is basically what's the trigger bang float is used for here.
In Axoloti you don't have to think about that, as all inlets are hot, control rate is updated 3000 times a second and audiorate is updated 48000 times a second.
Thanks for the reply!
Okay, interesting. I think this patch is basically doing the same. Would this be the most effective way of doing this?
If i'm not mistaken, all "float" signals come in the shape of dials in Axoloti, is that right?
Axoloti doesn't actually use floats as main variables. You can use them, but you need to do some conversion. Axoloti uses mainly variable types like int32_t(for dials), integers for number boxes.
This is one of the sides of Axoloti that creates some confusion and took a while for me to get used to. I know other had issues with this too, it takes a little while to get used to.
For the image, yeah that looks about right for division, if you want to divide 1 with 2.1.
Though the order of execution in Axoloti should also be taken into consideration. Order of execution goes from left to right and top to bottom. So in the case for the image you are posting, the order is:
1. const/i
2. rbrt/math/div fff
3. ctrl/dial b
If you want the right order you should probably set both values first, before doing the division. It's generally good practice to take that into consideration, as it can in some cases can cause issues with math. This is a bit more correct order:
1. const/i
2. ctrl/dial b
3. rbrt/math/div fff
Ok, interesting.. Will do my research on int32_t. Thanks for the clarifications!
Side question... I've been working with SirSickSick's pitch detector today, trying to make a kind of karplus strong guitar driven synth.
I copied the wiring of one of brucewallace's synth patch, but don't understand the values coming out of the object's pitch outlet, they're mostly negative values. Sending them through a mtof object, doesn't seem to make the synth match the string note either. In fact, the higher I play on the neck, the lower the synth pitch is.
My alloc is set to 85.33 ms.
Hey again!
About the pitch detection thing, I am not sure, haven't played around with it. Since @SirSickSik made it, he might be able to help you mire than I can.
If you search this forum for pitch detection, I am sure you will find something, within the last month or two, many people have asked about it. There are some working solutions in here for pitch detection for guitar.
first of all, I see a couple of weird things in the patch:
-why connect pitch output to damp input of the same module? This damp input is to remove higher harmonics, so these won't interfere with getting the base pitch. Connecting these to each other will probably make it wobble even more then it already does, especially with a guitar as input..
-you're using MTOF to control a delayline's time. Use the other version that is located in the delay folder as frequency-wise time goes up if frequency goes down.. Or put an inverter between pitch output and MTOF (it's what that pitch2time converter does when it converts the value).
but the main problem will be the guitar input. As plucking a guitar generates lots of higher harmonics without a root at the first stage of the sound, making a pitch detector jump all over the place. Seriously, it's réally hard to do a good pitch detection on a guitar because of all the overtones.. Hail the companies that got that to work! 
Probably some more lowpass filtering before detecting pitch might remove some more unwanted overtones, making it a bit more stable. But don't modulate the cutoff of these, as these will also influence the pitch being read out!
What you want is to make sure the root note, which is supposed to be the lowest frequency of your played note, will be the one that makes the zero-crossings and not some higher overtone. So use a 24/48dB lowpass before the pitch detection to make sure that the root frequency will ALWAYS be louder then ány posibble overtone. It doesn't matter if there's almost no sound left, even if it only goes above and under zero by just a tiny amount, this will set the zero-crossing. Still though, even if you completely finetune it, it will probably still generate some wrong values when striking a string.
I'm thinking that perhaps the pitch detection could still be improved by getting multiple pitches, so also some of the overtones. Then look to the ratio's of these frequencies to calculate which root-frequency is supposed to generate such overtones.
Yeah, I just copied @brucewallace 's use of your object. No idea why the pitch output is connected to the damp input. Didn't really get the chance to test it because I couldn't understand the values coming out of the pitch output. I'm used to Max MSP values, so I still have to get used to the lingo. I'll check out those objects in the delay folder and the "pitch2time" converter!
Either way, Bruce's use of your object works pretty nice I think! The monophonic pitch tracking is almost flawless on guitar... Only the lowest notes tend to struggle a bit.
it is? I'm pretty suprised by it myself haha
for those lowest notes, perhaps you can set the damp value a bit lower or use an extra lowpass filter to dampen high frequencies even more.
Especially low notes have some serious overtone peaks compared to the level of the low frequencies that could overtake and offset set zero crossing points.
I don't know if anyone here plays guitar, perhaps you could check out the patch yourselves..
I made some annotations above the objects i'm having trouble with. It's still a very basic patch and full of n00b mistakes, but I can't move on without the basis being fine ofc 
Me_GuitarKarplus.axp (9.8 KB)
I love the fact that you use a real guitar to trigger and play a synthesised guitar sound 
My guitar is in the basement so can test it atm. I think I need to fetch it soon, with all these cool guitar things coming up
haha, yeah. If i'm able to make a stinky, dirty electronic guitar i'd be a happy man.
Bruce's patch is almost perfect in pitch detection tho... I just need to figure out how his patch works.
The pitch output is fed back into the damp input to automatically scale the dampening response depending on whether the object receives a high or low note - it stops high notes choking from too much dampening, and stops high harmonics from interfering with low notes due to not enough dampening.
Hope that makes some sense! @TangoTits I replied to your PM - sorry for the wait.
