@nuromantix said:

Yes creating your synced oscillators at a high sample rate, filtering and then downsampling works but it's very processor intensive. I can find some much more efficient implementations in C++ but can't see a way to implement them in pure data.

There is no upsampling involved in j09.bandlimited.pd - it's a waveshaper that substitutes the infinitely short transition in a ramp for a short bandlimited one. Check it out

(If I am not mistaken the heavy library oscs implement the same technique)

@nuromantix I'm working on a bandlimited ramp/tri/saw osc based on 8 partials ([phasor~] going through 8 [cos~] objects with amplitude and phase mapped according to desired shape). It's a bit convoluted but not too heavy on CPU.

BLsaw-tri-ramp.zip

Amplitude and phase was mapped using FFT and a lot of math - same method can be used to map any morphing waveshaper of your desire

I'd post the mapping patch but it's a mess, so maybe later when I've done some clean up.

The problem with sync is you get infinitely sharp transitions at the sync point which you'd then have to bandlimit - maybe the trick used in j09.bandlimited.pd can be applied?

Also, please share your oscillators if you dont mind?

@oid said:

@nuromantix Triangles can be gotten from you saw, just run it through {abs~] and then multiply by 2 and subtract 1 to get levels back to normal. This assumes the saw has an amplitude of -1 to 1 and the saw is reasonably formed, if not a little futzing with the numbers and shifting the waveform should solve the issues.

The problem here is if your saw is bandlimited you will get weird spikes at the short transition.

Creation arguments are available via $1, $2, $3 etc inside the abstraction. Subpatches don't take arguments, but the ones from the parent patch are available.

See: http://write.flossmanuals.net/pure-data/dollar-signs/ for reference

Is your input audio signal or control message?

Without knowing much about your exact setup, here are a couple of ideas:

@lacuna said:

my example above is not suitable as zerocrossing detector, as the chance of a sample being actually 0 at zero-crossing is very small!
Detecting zero-'crossing' would be a transition from postive to negative or vice versa, or to zero. There is also [zerox~].

That's why there's a float margin you can set yourself in the patch i proposed. I have to admit the one sample delay differential detector is neat tho

Many control-rate objects operate in 64-sample periods, only. You can't change that. Even if [threshold~] would go down to 1 sample (still one sample late), the following message-chain won't.

Good point. And a cause of a great deal of frustration too >.< - We can only speculate as to what OP is looking to control, but if it's a [vline~] fade in / out I think that would be sample accurate? Also a 1 sample delay is easily ameliorated by compensation, i.e. [rzero_rev~ 0]

@ingox brilliant as always but we still have the problem of DSP block delay. I believe some stress-testing is in order

You can use [clip~] to create signal rate comparators/triggers like this:

You can modify this to check for as close to zero as you like (limit here being 2^-32), by running your signal through [abs~] and setting the float to your desired limit value.

This does however not output any bangs. The logical output is signal rate (which can be very useful). If you want bangs look into [threshold~]. You should be able to set that up as a zero crossing detector. The DSP block size will affect the accuracy of the timing though so if you need a bang exactly when your signal crosses zero, you will need to do [block~ 1]

@MDobleZ said:

I'm trying to create a wide-band spectrogram app for Android.

@MDobleZ said:

Apparently, it cannot be done, since you can neither force the sampling frequency to be low enough nor the blocksize to be high enough to get a narrow-band spectrogram.

Wide? Narrow?

There are numerous ways of representing a spectrum graphically with or without [rfft] . Most have been covered within PD vanilla (libpd compatible) over the years.

If [rfft] doesnt cut it because you want detailed info on formants between 300 to 1500 Hz, you can use [sigmund~] to single out frequencies/peaks on a bandlimited signal

@jameslo said:

@cfry Soundflower has attenuators....check that they are all the way up in Audio MIDI Setup.

I was gonna say this with no knowledge of reaper nor soundflower whatsoever: There is a very high likelyhood that there are adjustable gain stages between pd -> soundflower -> reaper. Don't try to make up for it in PD

Reverberation is one of my favorite subjects. Allpass filters with internal delay have been the basic building blocks of digital reverbs since the 60ties. The way they skew the phase of the dry signal adds a spectral smear similar to what a room does. I like to stack and nest and stack them and then cross feed between 2 channels for some cheap but decent sounding room reverb. Takes some fine tuning though...

Your own sounds surprisingly good (albeit old school) for just an allpass filter with delay. I wonder if there is any secret voodoo to cyclone's allpass implementaion I don't know about...

You should try hooking up more than one and tune them differently, also experimenting with how much bleeds into the next vs dry feed and then do a mix of all - there are endless combos to explore

You can do allpass filters in vanilla quite cheaply btw ->vap~.pd

Could be optimized to take creation arguments for initial delay and gain. Or you could change the [delread~] to [delread4~] and have signal rate modulation of the delay time (for oozy 80ties chorussy verb effect).

(Would like to know if there is any difference in sound between cyclones external and my vanilla abstraction....)

Edited to fix certain convention flaws and typos in the patch + elaboration

@oid said:

@bocanegra how did it become buggy? My guess would be it is something in cell.pd, deleted something I should not have in that bit of afterthought cleaning. Will check later if someone does not find the issue.

I always test the game with a simple XXX oscillator. It cancels out to nothing over 4 generations in your patch when it should be oscillating.

Ultimately each cell only needs to be a single bit memory, everything else can be moved out. So a toggle with its sends and receives properly set will do nicely and make it simple to dynamically patch the field. But we need to leave some room for @SignalsInNoise to learn, cant just hand him a perfect completed patch.

Agreed. And I am trying real hard to keep my hands out of the patch

Each cell banging the next is just rolling your own loop, which can be useful but has issues since creation order starts playing a roll. We have [until] for looping, it is more efficient, gives a more readable patch and almost fool proof, you need a good reason to roll your own.

I have less experience with the control domain, but my gut tells me the same: the cells are feeding in to each other (not just one way) and are causing non-deterministic behavior. Tighter control of what happens when is needed. This is a case for @ingox