Hi,

I recently made an interesting discovery. I have been using a midi controller I made to use as controls for a looper in Pd. When I press a button for a loop function an LED usually turns on to give me visual feedback. If I turn on an effect, an LED turns on. Play, stop, reverse, speed change, etc, an LED turns on.

This looper has always been buggy and glitchy. it's never really worked right and I always assumed I had some timing thing off or I made a mistake in the patching.

I accidentally discovered today that If I disable all the LEDs it works perfectly. I think Pd is prioritizing the LEDs over the audio processing or midi messages. I know in Max there is a way to disable this by turning "overdrive" off in the Audio Settings window.

Is there a way to prioritize the MIDI and Audio over LEDs in Pd so I can still use LEDs, but their timing isn't exactly perfect? Or even at least some of the LEDs? I use ctlout objects to turn on the LEDs.

Thank you in advance for any possible suggestions.

@Chalisque

short answer: you have to make sure that the data runs in the high priority thread.

pd and max have a main thread, a high priority thread (overdrive), and an audio thread (among others)

how to do that in C++ is surely documented in the SDK examples, but i will not be of much help here.

maybe compare the source code of [+ ] vs. [delay], the latter outputs to the high priority thread if one exists.

could it be that the loadbang message inside my abstraction is overdrive my arrguments freom outside the abstraction (4000, 1000) ?

@WEIRD1 PAs will not care much about square waves unless they are the ones making the square waves, so don't overdrive the PA and you will be fine. If you want to soften them up you can do that with a lowpass filter like [lop~].

@tungee - the feedback chain has a softclipper (tanh function) that makes it overdrive at >3 resonance but never hit the 1/-1 clipping wall. Try cranking it up to 25 and see. Or open it up and bypass the [expr~ tanh($v1/5)] object in the feedback path - but then your should be careful with resonance values > 1...

@Booberg Slew rate in electronics does not itself alter phase (arguable) as it is a byproduct, but there are countless things in most circuits which do alter phase. We use capacitors to block the DC voltages between different stages of the circuit so the DC voltages which set operating points for those stages don't interact with each other and alter the operating point of the other, these capacitors form filters with the resistances around them, phase is a much more fluid thing in the real world and less perfect than in the digital world. Sometimes we design out these capacitors to avoid these effects and directly couple the various stages in a circuit but this creates a teeter totter effect, altering one stage affects the others so you have to adjust them all and rebalance everything. But slew rate is not an issue in something like the transistor ladder since its effects will be insignificant compared to the effects of the filter unless the the cutoff is all the way up and Q all the way down and even then would likely be lost behind the circuits distortion and noise.

I do not know of any really good software transistor ladders, most if not all mimic the circuit as a whole instead of the individual stages which make up the circuit, this largely removes the highly interactive nature of the the stages and the controls but it is more CPU efficient and makes the filter respond as most people expect a filter to respond. The filter has four major components from the audio standpoint, input amp, the transistor ladder itself, the recovery/output amp, and the resonance path, each of these tailors the frequency response and distortion characteristic of the overall circuit and each of these influences how the others do this. Generally the primary source of distortion is the output amp loading down the ladder, but we can also overdrive the input for a different sound and high resonance settings will overdrive the ladder itself, changing the filters frequency can completely remove the distortion effects of the output amp and make the other sources primary and they each have a very different sort of distortion. We have four distinct sources of distortion and tone shaping besides the ladder at the core and all but the input circuitry are affected to some degree by the cutoff control voltage since changing the cutoff changes how the ladder loads the output amp which changes how the resonance path drives the core and loads the output stage. I know of no emulations which bothers to model all of this, they seem to all fixate on getting that handful of stereotypical sounds and call it good because they know that the first thing most people are going to do is set it for one of those sounds and if it gets that sound they will be convinced of it's authenticity, most have not spent enough time with the real thing or done extensive analysis of the circuit, they only know those stereotypical sounds, not how it responds to the musician.

Edit: I don't know if any of this actually matters or if anyone would notice the difference between the simplified emulations and an accurate one, musicians tend to be more practical than engineers and the practicality of my musician side lost out to my curiosity in such matters long ago. The real thing does respond much more like an acoustic instrument than an electronic instrument, which is why the mini was the first big success in synths, but I am not sure that plays any role these days.

LTSpice may be available for OSX, I don't actually know now that I think about it, if you have wine installed the windows version runs perfectly there. Check their site, it is free. I do not believe you would be able to run its circuits with other simulators but I could be wrong, the file syntax might just be plain old Spice.

@bocanegra Fun, I didn't know there was a name for that. Cyclone has tanh~ and overdrive~ in case you weren't aware.

I made something similar 5 years ago when I was experimenting with wavefolding. It's sort of like fractional recursion of the second half of cosine, if that makes any sense
deformPhasor~.pd
deformPhasor~ show.pd

Here's another one based on [log~]: logShaper~.pd

This is my best attempt at a "vacuum tube" style overdrive.
(Edited)
Look below for the latest version. This relies on Zexy ( for simple single sample delay) and Else. The only thing i could not easily build in vanilla was the Hysteresis emulation, which relies on lag2~ and glide2~.

This older version is quite different and messy. Mostly experimentation.
ThurboDrive~.pd ThurboDriveExample.mp3

I have made three guitar effects so far as part of a guitar multi effects patch. Overdrive, Delay and Chorus. The effects work perfectly fine, I am just having problems routing them together. I want to be able to route them in a chain e.g adc~ --- Overdrive --- Delay --- Chorus --- dac~ with the ability to bypass/mute different effects when required. I don't want the effects to run parallel as the overdrive overpowers and it does not sound right. Has anyone got any suggestions on how I can go about doing this?

@oid

14 channels of monophonic sequencing, 32 steps with probabilities

2 channels of polyphonic sequencing each with 4 polyphony, 32 steps with probabilities

14 sample based monophonic sound generators at 24/44.1 each with basic adsr envelope and multimode filter and overdrive

2 channels of polyphonic sample based generator with help of synths engines each consist of 3 envelops and 3 lfos, 1 multimode filters, basic sample scan (taking in consideration the granular aspect if is not a cpu hungry process, but I suspect it is)

total of 16 insert effects, one for each channel, send return reverb and delay and a basic master chain effect with multi-band compressor and a limiter.

so a total of max 22 channels polyphony of sample engines at 24/44.1 with a really low buffer size to allow midi sync capabilities in very good stability state.

@oid said:
You really need to work out a full spec before sane help can be offered.