Hello everyone, I have a question, i want to start performing with my sound drawings live; my sound drawings are reproduced with sine waves, I use Iannix for composition and Pure Data reproduces the score. But for live performance it ocurred to me to reproduce them with police sirens. Iannix communicates with Pure Data through Open Sound Control. Arduino does not support open sound control directly, there must be a bridge that converts open sound control to serial data that arduino can understand, i researched and that bridge can be pure data, (i could make the police siren through arduino).

My question is if arduino can reproduce the iannix curves just like pure data does, that is, reproduce the iannix curves exactly like they are written, i use iannix curves mainly for composition, these curves can play separate notes or glissandi...

I use open sound control and sine waves because that is the only way to reproduce the iannix curves exactly the way they are written (midi does not follow the curve exactly, osc can, and i enjoy the sound). (the curves can be in any direction and last as long as i want with any kind of shape, acceleration or slowing down, and open sound control and the sine waves can follow them perfectly, but not midi)

So... I am willing to learn how to code for arduino if it can reproduce my scores the way they are written (just like pure data has done), i gotta feeling that it is possible, but before buying an arduino card i want to know for sure.
Here is an example of a iannix score:

So iannix would send open sound control to pure data, pure data would convert open sound control to serial data and arduino would receive the serial data and play the score through a speaker.
can this be done? thanks.

Hi everyone,

I'm working on a system to automatically generate a vline~ message list starting from a custom envelope shape stored in an array, originally extracted from a .wav file.

I want to build a dynamic vline~ list like this: 0, 1 93.753, 1 0 187.506

But instead of typing values manually, I'd like to generate it automatically based on the shape of an envelope loaded from a waveform (array).

I already convert the array index to milliseconds using: [expr ($f1 / 44100) * 1000]
And I can manually draw or extract the envelope into an array — but I’m struggling to automate the construction of the vline~ list so it correctly represents:

• attacks
• holds
• releases
• plateaus (ecc)

at the moment i Load a .wav file containing an envelope shape, Store it into an array. Detect meaningful breakpoints (e.g. slope changes, thresholds) and Use those to automatically create a proper vline~ sequence.

here the patch and one env wav file
impose-envelope-wavetable-analog.pd
strike-1_6.wav

Is there a way to extract breakpoints or slope changes from an array to build a proper vline~ message?
Has anyone implemented something similar (using an envelope from a .wav as a wavetable)?
Would “wavetable envelope” be a good term for this? Is there a better one in Pd terminology?

Thanks in advance if anyone has ideas or guidance.
Even partial thoughts or pointers would help a lot!

I almost forgot: At the moment, I’m using GPT to convert the vline~ list into the format 0, 1 93.753, 1 0 187.506 (just an example), starting from a total duration in milliseconds — in this case, 2176 ms. This naturally results in very complex lists, like something along these lines:
0, 1 100, 0.6 400 100, 0.3 2000 500, 0.15 3000 2500, 0 10491 5500

I’d really like to find a way to resolve this and automate the process, but since I’m still a beginner, I wonder if I’m just making things unnecessarily complicated?

Emiliano

Ok, the cat is out of the bag --> https://github.com/porres/pd-else/releases/tag/1.0-rc13 I'm officialy announcing the update and uploaded binaries to deken for mac (intel/arm), Win and Linux. It all looks ok but tell me if you see something funny please. There's also a raspberry pi binary but not working 100%yet and we'll still look into that. Hopefully someone could help me/us with it. I might make another upload just for the pi later on if/when we figure it out. Find release notes and changelog below.

---

RELEASE NOTES:

Please support me on Patreon https://www.patreon.com/porres I'll now try to add special content for subscribers. You can follow me on instagram as well if you like... I'm always posting Pd development stuff over there https://www.instagram.com/alexandre.torres.porres/

It's been a little bit over 7 months since the last update and I almost broke the record for taking too long to release an update (which had happened in my previous update). So yeah, there's just too much to talk about! I guess the delays in releasing updates is because it's been a little tricky and hard to sync the release cycles of ELSE with PlugData, which includes ELSE in its download.

Plugdata 0.9.2 should come out soon with ELSE RC13 and it's supposedly the last update before 1.0.0, so I've heard. And the plans was to get to that still in 2025! This means ELSE could be at its last "Release Candidate" phase as I'm aiming to sync the final release with PlugData. Until then, I'll still make breaking changes and I can't wait until I can't do that anymore as I really feel bad. On the other hand, it's kind of inevitable when I'm always adding new stuff and redesigning and reconfiguring objects to include more functionalities. And I always got a lot of new stuff! So I'm thinking that I will eventually try some mechanism like Pd's compatibility flag or something. I'll try to come up with something like that in the next update.

This update has 22 new objects for a total of 573 and 26 new examples in my tutorial for a total of 554 examples. Let's dive into the highlights (see full changelog below after the release notes).

• Multichannel Support: Last release had 92 MC aware objects, now it's 139! Over a 50% increase that include old and new objects (all the new ones have been coming with MC support). Virtually all oscillators and envelope generators now have MC support, plus some other random ones. Let me highlight the new [lace~]/[delace~] objects that are 'MC' tools that perform interleave/deinterleave in Multichannel connections. My bare minimum number of objects "to start with" would be at least a bit over half the number of signal objects. That was my target for 1.0! ELSE right now has 319 signal objects, so that'd be at least 160. I will definitely pass this milestone in the next update. I guess a good number of MC objects would be around 75% of the signal objects. I will aim for that as soon as I can. Some objects simply can't be MC at all, so 100% will never be the case, but maybe an ideal 90% eventually? We'll see... I am just proud and happy that ELSE is taking such a big jump on MC awareness in less than a couple years.

• Envelope generators ([adsr~]/[asr~]/[envgen~]/[function~]) now have more curve options. For [adsr~]/[asr~] the default is now a new log curve that you can set the curve parameter (and was 'stolen' from SuperCollider). A new [smooth~] family of objects perform the same kind of curved smoothening for alternating inputs - [envgen~] and [function~] also have that but also '1-pole' filtering, 'sine' and 'hann' curves. You can now trigger [adsr~] and [asr~] with impulses.

• The [play.file~] object now supports even more file formats besides MP3 and stuff. Hey, you can even stream the supported formats from weblinks! The [sfload] object (which loads files into arrays) also gained support for more formats and can download from weblinks as well! It also has a new threaded mode, so loading big files won't choke Pd. It now also outputs the file information, which is a way to tell you when loading finished in threaded mode. The [sample~], [player~], [gran.player~] and [pvoc.player~] objects are now also based on [sfload], so they support all these file formats!!! Now [sample~] and [tabplayer~] are integrated in a way that [tabplayer~] is always aware of the sample rate of the file loaded in [sample~] (so it reads in the "correct speed"). A new [sfinfo] object is able to extract looping regions and instrument metadata information from AIFF files (which is something I wanted for ages) - it should do more stuff in the future.

• [knob] has become the ultimate featured bloated creep GUI I always feared and avoided. MAX is envy! but I'm happy with this structure and I want to replicate in other GUIs in the future (yeah, I got plans to offer alternatives to all iemguis). I wanna highlight a new 'param' symbol I added that allows you to remotely set a particular method in an object, so you don't to connect to a "method $1" message and you can even do this wirelessly with a send symbol. [knob] now also acts like a number box, where you can type in the value, which may also be displayed in different ways or the value can be sent elsewhere via another send symbol so you can temper with it using [makefilename] or [else/format]. I've been using this for the MERDA modules and it's really cool.

• We finally have a [popmenu] GUI object! This was in my to do list forever and was crucial to improve the MERDA modules to set waveforms, instruments and whatnot.

• Let's about MERDA, the "Modular Euroracks Dancing Along" subset of abstractions in ELSE. It was first released in the last update and it's been driving lots of the development in ELSE as you can see. I now added a MIDI Learn feature for all knobs that feels great and quite handy! There are many fixes and improvements in general and some new modules. I wanna highlight the new [sfont.m~] module, which loads "sound font" banks and you can just click on a [popmenu] to choose the instrument you want. The default bank has numerous (hundreds) options and also comes with PlugData. The sequencer module [seq8.m~] was rather worthless but it's now a whole new cool thingie. It allows you to set pitches with symbols and even has quarter tone resolution. I added a right outlet to send impulses to trigger envelopes and stuff (there's still more stuff of course, see full changelog below).

• There are newly designed/renamed/recreated [resonbank~]/[resonbank2~] objects that are well suited for Modal Synthesis.

• What actually drives my development is my Live Electronics tutorial, which got a fair upgrade with a new chapter on Modal Synthesis amongst other things, such as new subtractive synthesis examples and a revision of envelope generators with examples on AHDSR and DAHDSR - by the way, there are new gaterelease~/gatedelay~ objects for handling envelopes (and other processes).

• I have to thank some people. Tim added 'zoom' to the [pic] object, as well as an image offset. Tim also implemented a new and better technique for bandlimited oscillators. Ben Wesh gave me a new [scope3d~] GUI object, pretty cool, that plots an oscilloscope in 3 dimensions, which is coded in LUA - and ELSE has been carrying a modified version of [pdlua] because it now depends on it for a couple of GUIs. Tim and Ben made many improvements to [pdlua] (as well as Albert Graef, of course).

• For more new objects, let me also tell you about the simple and cool [float2imp~], that is based on [vline~] and can convert floats to impulses with sample accuracy (don't know why I didn't think of that earlier). A new [tanh~] object has Multichannel support. A bit earlier I made an update to Cyclone that actually "borrows" and includes this one from ELSE instead of its original one (which does not have Multichannel support). PlugData users will load the one from ELSE. This is another tiny step that sort of integrates ELSE and Cyclone, specially for PlugData users.

happy patching.

---

CHANGELOG:

LIBRARY:

Breaking changes:

• [adsr~]/[asr~]: now a gate off before reaching the sustain point does not start the release right away (this allows you to trigger it with impulses). There's a new mode just for immediate release. There's a new exponential setting for curve factors, the old 'log' mode is renamed to 'lag' as it's the same as used in the [lag~] object. For [adsr~], a bang now is not "retrigger", but an impulse at control rate, there's a new 'retrigger' message for control rate retriggering (and now it only retriggers if the gate is on). For [asr~] a bang now also works like an impulse.
• [sample~]: no more 'load' message, args to 'open' message changed, size is now only in 'ms'.
• [format]: outputs are now always symbols, before you could get float outputs. Also, we just have a simplified symbol output, no more lists or anythings. Hopefully I'll be able to get the 'list' output back, but it involved some bugs that I couldn't fix so I just removed it. You cannot use bangs and lists in secondary inlets no more (this is cylone/max crappy paradigm we don't want here). Bang method was actually removed as well.
• [pack2]: no more support for anythings, also no more support for lists in secondary inlets and output has a list selector (I wanna make this more Pd like and not a silly clone from MAX's [pak], cause fuck MAX).
• [merge]/[unmerge]/[group]: no more '-trim' flag (again, respecting pd's usual list paradigm), in [merge] now there's no more 'hot' argument and a bang now represents an empty list and inlets initialized with empty lists
• [mono]: 1st argument is now 'glide' in ms.
• [sfont~] now uses 'mma' for bank selection (this alters how CC messages set the bank number).
• [player~]/[play.file~]: 'open' message does not play files right away anymore.
• [tabplayer~]/[player~]: play message without args now play at the default settings (whole file at regular speed).
• [envgen~]: removed the 'maxsustain' parameter, use the new [gaterelease~] or [gaterelease] objects instead. Removed the rightmost inlet just to set envelopes, now a list input only sets the envelope and doesn't trigger it. The 'set' message is then removed.
• [envgen~]/[function~]: simplified and got rid of '-exp' flag and message, also deleted 'expl' and 'expi' messages. A new 'curve' and cimpler message sets exponential factors for all or individual segments, and includes more curve formats.
• [knob]: 'esc' key now deactivates the object. The 'ticks' message is renamed to 'steps' and there is a new 'ticks' message that toggles showing ticks on and off. The 'start' message has been renamed to 'arcstart'. The 'outline' message has been renamed to 'square' for better clarity. Design changed a bit to make it like it is in PlugData (they won), so we now fill the whole background color when in 'square mode' and the knob circle has an 85% proportion in this case inside the full 100% square size (so it grows bigger when not in 'square' mode). Now, by default, the GUI is in a new 'loadbang' mode (I don't think this will influence old patches). I'm afraid some old patches might behave really weird since I added a lot of new stuff. I changed the 'load' message behaviour to not update the object (this can arguably be considered a bug fix).
• [wavetable~], [bl.wavetable~] and [wt2d~]: 'set' message now sets frequencies because of the MC support in [wt~] and [wt2d~], while there's a new 'table' method to set the table name.
• [gbman~]/[cusp~] list method is now for MC, old list method is now renamed back to an old 'coeffs' method.
• [f2s~]/[float2sig~] default value is now 10 ms.
• [op] now behaves like [*~] where the smaller list wraps til reaching the size of the longer one.
• [list.seq] does not loop anymore by default.
• [impseq~] list input removed, use the new [float2imp~] object to convert floats to impulses.
• [resonant~] now has 'q' as the default.
• [resonant2~] has been removed.
• [decay2~] has also been removed ([asr~] much better).
• [vcf2~] has been renamed to [resonator2~].
• [resonbank~]/[resonbank2~] have basically been deleted and replaced by new objects with the same name... [resonator~] is based on a new [resonator~] object which is similar to [resonant~] and [resonbank2~] is now based on [resonator2~] (old [vcf2~] instead of [resonant2~] that got deleted). These are well suited objects for Modal Synthesis.
• [oscbank~] now uses a 'partial' list and not a frequency list. The freq input now defaults to '1' and this makes [oscbank2~] completely obsolete.
• [oscbank2~] has been deleted since it became completely obsolete.
• [sfload] load message changed the behaviour a bit.

Enhancements/fixes/other changes:

• [adsr~]: We have now a new mode for immediate release (see breaking changes above, I'm not repeating it). Fixed ADSR signal inputs (it was simply not really working, specially for linear). Fixed status output for MC signals. There's a new curve parameter that allows you to set the curvature.
• [asr~] I actually just made the new [adsr~] code into a new [asr~] code as a simplified version (as it was before)... so it's got the same impromevents/fixes.
• [play.file~]: added support for more file formats and even weblinks for online streaming!
• [sfload]: added an outlet to output information, added threaded mode, added support for more file formats and even weblinks for downloading.
• [sample~], [player~], [gran.player~] and [pvoc.player~] are now also based on [sfload], so they support more file formats!
• [sample~]: improved extension management with [file splitext].
• [sample~] and [tabplayer~] now are automatically integrated in a way that [tabplayer~] is always aware of the sample rate of the file loaded in [sample~], so it automatically adjusts the reading speed if it is different than the one Pd is running with.
• [numbox~]'s number display is not preceded by "~" anymore (that was just kinda stupid to have).
• [format]: fixed issues where empty symbols and symbols with escaped spaces didn't work. Added support '%a' and '%A' type. Added support for an escaped 'space' flag. Improved and added support for length modifiers. Improved syntax check which prevents a crash. Improved documentation.
• [knob]: added new 'param', 'var', 'savestate', 'read only', 'loadbang', "active", "reset" and 'ticks' methods. Added the possibility to type in number values and also modes on how to display these number values, plus new send symbols for 'activity', 'typing', 'tab' and 'enter'. New design more like plugdata. Changed some shortcuts to make it simpler. If you have the yet unreleased Pd 0.56-0 you can also use 'double clicking' in the same way that works in PlugData. Properties were also significantly improved (I'm finally starting to learn how to deal with this tcl/tk thingie). Yup, a lot of shit here...
• [autofade2~]/[autofade2.mc~]: fixed immediate jump up for 0 ramp up.
• [synth~]: fixed polyphony bug.
• [metronome~]: fixed bug with 'set' message.
• [midi2note]: fixed range (octaves 0-8).
• [pulsecount~]: fixed reset count to not output immediately, added bang to reset counter at control rate
• [click]: fixed regression bug where it stopped working.
• [else]: new 'dir' method to output ELSE's binary directory in a new rightmost outlet. The print information also includes the directory.
• [pic]: added zoom capability finally (thanks to tim schoen) and added offset message (also thanks to tim).
• [store]: added 'sort' functionality.
• [scales]: fixed octave number argument. Added functionality to allow octave number as part of the note symbol.
• [mono]: added 'glide' parameter, as in [mono~].
• [pluck~]: fixed list input.
• [rescale]/[rescale~]: added a "reverse log" mode.
• [limit]: added a new second ignore mode.
• [graph~]: added an external source input for plotting the graph and a 'clear' message.
• [canvas.setname]: added a new argument for "abstraction mode" and methods to set name, depth (and mode).
• [midi.learn]: added a new argument for "abstraction mode", fixed 'dirty' message sent to parent.
• [brickwall~]: fixed initialization.
• [list.seq]: added a loop mode and a 2nd outlet to send a bang when the sequence is done.
• [delete]: fixed index for positive numbers.
• [dust~]: added 'list', 'set' and '-mc' flag for managing the already existing Multichannel capabilities.
• Thanks to Tim we have many fixes and a whole new technique for band limited oscillators. Now [bl.saw~], [bl.saw2~], [bl.vsaw~], [bl.square~], [bl.tri~], [bl.imp~] and [bl.imp2~] have been redesigned to implement elliptic blep, which should provide better anti-aliasing.
• [parabolic~] now uses and internal wavetable for more efficiency.
• [resonant~]: added 'bw' resonance mode.
• [lowpass~]/[highpass~]: added 't60' resonance mode.
• [quantizer~]/[quantizer]: added a new mode, which combines floor (for negative) and ceil (for positive) values.
• [crusher~]: now uses the new [quantizer~] mode from above (arguably a breaking change).
• [envgen~]: fixed a bug (actually a misconception) where ramps started one sample earlier. Fixed 0-length lines. Added a possibility to set time in samples instead of ms. Maximum number of lines is now 1024. Added loop mode. Added many curve options (sin/hann/log curve/lag).
• [function~]: Added many curve options (sin/hann/log curve/lag).
• [The out~] family of abstractions now use [bitnormal~] so you won't blow your speakers beyond repair in edge cases.
• [trig.delay~]/[trig.delay2~]: fixed bug where impulse values different than '1' didn't work.
• Added MC support to: [trig.delay~], [trig.delay2~], [gatehold~], [vca.m~], [gain2~], [decay~], [asr~], [envgen~], [function~], [bl.osc~], [bl.saw~], [bl.saw2~], [bl.vsaw~], [bl.square~], [bl.tri~], [bl.imp~], [bl.imp2~], [imp2~], [tri~], [saw~], [saw2~], [vsaw~], [square~], [pulse~], [parabolic~], [gaussian~], [wavetable~], [wt2d~], [randpulse~], [randpulse2~], [stepnoise~], [rampnoise~] [pink~], [gbamn~], [cusp~], [gray~] and [white~].
• Also added MIDI input and soft sync to [imp2~], [tri~], [saw~], [saw2~], [vsaw~], [square~], [pulse~], [gaussian~] and [parabolic~].
• [wavetable~] and [wt2d~] gained args to set xfading.
• Updated pdlua to 0.12.23.
• M.E.R.D.A: Added MIDI-LEARN for all modules (this is only for the knobs). Replaced some number boxes that were attached to knobs by an internal number display mechanism (new feature from knob). Improved interface of [gendyn.m~]. Preset/symbol name fixes to [flanger.m~]. Now we have automatic MIDI mode detection for [plaits.m~] and [pluck.m~] when no signals are connected (still trying to get plaits right, huh? Yup! And bow MIDI input with monophony and trigger mode has been fixed in [plaits.m~]). Added MC support to [vca.m~]. Increased range of [drive.m~] down to 0.1. Changed some objects to include the new [popmenu] GUI. [vco.m~] now uses the new MC functionalities of oscillators and doesn't need to load abstractions into [clone], I hope it makes this more efficient and clean. The [seq8.m~] module was worthless and got a decent upgrade, it's practically a new module. Added new modules (see below). Note that MERDA is still at alpha development phase, much experimental. Expect changes as it evolves.
• 22 new objects: [float2imp~], [lace], [delace], [lace~], [delace~], [gatehold], [gatedelay],[gatedelay~], [gaterelease~], [gaterelease], [popmenu], [scope3d~], [tanh~], [resonator~], [sfinfo], [smooth], [smooth2], [smooth~], [smooth2~], [dbgain~], [level~] plus [crusher.m~], [sfont.m~] and [level.m~] MERDA Modules.

Objects count: total of 573 (319 signal objects [139 of which are MC aware] and 254 control objects)!

• 323 coded objects (210 signal objects / 113 control objects)
• 227 abstractions objects (87 signal objects / 140 control objects)
• 23 MERDA modular abstractions (22 audio / 1 control)

---

TUTORIAL:

• New examples and revisions to add the new objects, features and breaking changes in ELSE.
• Added the MERDA modules into the examples for reference.
• Revised section on envelopes.
• New subtractive synthesis examples.
• New chapter on Modal Synthesis.
• Total number of examples is now 554! (26 new ones)

---

@brendanmac there's some vanilla abstractions (meaning they should work in purr data, plug data as well as PD vanilla, theyre just made out of the most basic pure data vanilla objects), copy these to the same folder you are working in and type os.square~ into an object box aka [os.square~] , then right click the help (or just open the help file) os.square~-help.pd os.square~.pd
these and other goodies are in mkmr to get you going quick in most of the flavors of pd because theyre vanilla https://github.com/MikeMorenoDSP/pd-mkmr
some other good links at https://github.com/MikeMorenoDSP/awesome-puredata

@brendanmac lets look at it.

from an electronics perspective it looks like a square wave represents a steady DC signal the closest (meaning if you were to flip the 0 to -1 part it would be a straight line) besides at the crossings and the others look filtered.

Its interesting how there's a subtle difference at the peak of a sine vs a triangle, the sine hits red a little. In vintage analog synths a "dirty" triangle wave could be mislabeled on the synth as tho it is a sine but it looks like it has the least energy. Also from vintage synths if you look at the waves in a scope they look different than you would think, especially something like a 303 (filtering out the DC maybe?). A function generator (which this basically is) is more like what you think of these basic waveforms in your head.

the live electronics tutorial included in [else] is top notch btw (as is the audio section in the help browser, thats supplemented with a free online book on miller's website). a saw has all the harmonics, a square odd, triangle even, and they can be separated or combined. a (co)sine wave is the only signal that can travel through electronics without change phase (which can mess up what you are seeing) one reason why its used to probe inside audio electronics

also to note, the oscope~ on the top was just to show that the [phasor~] normally comes out at 0-1 (normalized float which is easy to use as a looping function) so it has to be stretched out to be used like a sawtooth
testWaves.pd

@brendanmac If I remember correctly from school the power of a signal is the area under the curve.... which is why a compressed signal (then normalized) sounds louder and compression is often used when mastering a recording.
A square wave has a large area under the curve..... it is always at +- 1 ....... and will be 6db louder than a sine wave for the same peak values.
A saw contains all the higher harmonics (like the square wave) but the perceived loudness has more to do with the richness of the timbre than the actual power I think. The square wave of course also has that perceived increase in power from the harmonics.
A saw wave actually has less power than a sine wave, so the effect is purely psychoacoustic.

The harshness comes from the higher harmonics (especially the highest), so you cannot change that. A low pass filter will progressively return the waveform to a sine as the cut off frequency is reduced, because the higher harmonics are being reduced...... and it will introduce a phase shift (a slight lag in the waveform).
A wavetable will produce the same effects as your maths...... it is in the nature of the waveform and there is nothing wrong with your method.
You can use a [lop~] to reduce the effect though if you actually want a less harsh sound.
David.

@manuels I was not prev aware of these other kinds of white noise but they are all smooth and so don't produce the kind of texture I want. To give you a sense of what I'm looking for, here is the sound of a drip into an empty tin can: tinCanDrip1.wav. Convolved with binary white noise, you get this: tin can conv binary noise.wav. Now here is my nasty-sounding whitening of bubbling water and it's convolution with the tin can: whitened bubbling.wav & tin can conv whitened bubbling.wav. See how the result sounds a little like a small stone being rolled around the bottom of the can?

Also, that's interesting about [noise~] in overlapped windows, I'll go back and modify my version of that patch to see if the lo-fi mp3 quality goes away.

@whale-av "randomly modulated in its amplitude"--yes, that's what I tried with the 64 band 1/5 oct graphic. It's not bad, but it's not natural sounding either. Could be useful anyway, depending on the effect you want.

@ddw_music My problem isn't the convolution (I'm using REAPER's ReaVerb for that), I'm just wondering how to make the kind of IR that produces the effect I want. Your rifft strategy is what I speculated about in my original post and what I first tried using [array random] to generate freq domain moduli with a similar distribution as [noise~]. FYI Pd's real inverse FFT automatically fills in the complex conjugates for the bins above Nyquist, so you don't have to write them--leaving them as all 0 is fine. Also note that your [lop~] is filtering the change between successive bin moduli in a single window, not the change of each bin from window to window. I'm speculating that the latter (maybe using asymmetric slewing rather than low pass filtering) would make frequency peaks hang around longer (and hence more audible) whereas I'm not sure what the former does. That said I think the strategy of modifying natural sound is paying off faster than these more technical methods.

Hi all,

I'm creating a project with lots (literally hundredths) of samples I want to play kind of randomly. I'm new on PD, and right now I'm working on my prototype with the classic message [open soundfile.wav, 1] to play each one of them. But I need to scale it more efficiently and I'm not finding a solution. Does anyone know if there is a method to group different files in a message and select one of them randomly?

I was wondering if it is possible to build something like this:

[O]
|
[random 858]
|
[sel $1]
|
[O]
|
[file_0.wav, file_1.wav, file_2.wav, file_3.wav, file_4.wav, file_5.wav (...) file_857.wav]
|
[readsf~]
|
[dac~]

Thanks in advance, I'm learning a lot in this community.
Cheers!

In order to transition from a sine wave to a triangular wave, I combinined the two sound waves by adjusting the gain of the two waves to each other, i.e. the triangular wave gain (a) drops uniformly from 1.0 on the left to 0.0 on the right, while the sine wave gain increases accordingly (always 1-a).

It worked well at first. However, when I ran it again, the volume changed. The exact same procedure, which I can only explain in metaphysical terms

Maybe someone can answer it for me? Thanks so much
Here is the picture view of my problem：

Hi, I'm looking for someone with a deeper understanding of PD and audio synthesis to help me understand why my patch sounds the way it sounds. I don't know why the audio is generated this way. I don't know if it is because of some expected behavior of square waves and the math behind it, or if it is because of some quirk of PD and the way I'm generating the square wave. If you think you can help, please stay with me, I don't know who to go to or what to study to help me understand this.

I was attempting to make a square wave from scratch, I saw some tutorials and I know there are more "proper" ways of doing this, but the simplest I could think of was -1 and 1 alternating. The osc I built is a metronome with a route alternating between -1 and 1 at a given hertz. But the result doesn't sound like a single square wave, there are some harmonics, almost like having senoidal waves mixed with the square wave.

Experimenting, I noticed a cycle of the resonances going from 1hz to 1378.125hz where it completely stops, like zero hz, or one tick in several, several minutes. Other cycles multiples of this frequency exist, like this:

n=1378.125hz
Cycle0 = 1 to n* 2^0
Cycle1 = n*(2^0) to n*(2^1)
Cycle2 = n*(2^1) to n*(2^2)
Cycle3 = n*(2^2) to n*(2^2)
? Cyclen= n2^(n-1) to n(2^n) ?

C0 and C1 are very similar, with subtle differences, but inside of C2 it seems like 2 times C0 or C1 (I didn't check it, but it sounds like this). Inside C3 there are 3 times, and next, C4, 4 times, and so on, the same cycle but more times and faster in each power of two.

I have made a patch that makes it easy to clone the osc to generate each Cycle. For example, clone 10 times to get audio files from C0 through C9.

Where do the resonances come from? Why these cycles exist? Are they some kind of harmonic series? Why 1378.125hz? Is this expected from the math, or is it a quirk result of some PD object (like inputing very low numbers to the metronome)? Does someone understand why this is happening?

main_oscs_cycles.pd
square-from-scratch-osc.pd used in main
square-from-scratch-osc-lineramp.pd used in main