Thank you.

Going back to the question of overlapping graphs, in this sample patch I would like to overlay 10 graphs of random numbers:

array2.pd

What I was looking for, was to use a single array message like:

[s array $1 (

passing the values ​​to $1 from a [counter] ...but I haven't been able, it doesn't work.
So in that patch I created an object for each array in this way:

Same thing for messages to clear graphs, I was looking for something like:

[; array$1 const 0 (

but it only worked by creating one for each array.
If the graphs were 100, it would be difficult to do all this.

Regarding the quality of the graph: I have seen that no points are created but segments (evident in the image of your last post).
So, to draw a point cloud, remaining in pure data, soon I'll try with "data structures" , using for each point a circle of minimum possible radius. I just started reading some tutorials.
Otherwise of course I export the data (x, y, z) and use an external software. But I'm curious to see what I can do by always remaining in Purr-Data.

P.S.:
Purr-Data, when I use [prepend something] it always gives me a warning that says:

[prepend]: this object is a legacy replacement for prepend in cyclone library that is considered deprecated in pd-l2ork. Please use [list prepend] and [list append] instead.

So I should replace a single object with two objects:

[list prepend something]
|
[list trim]

In the patch above I tried to do this replacement, and it no longer gives me the warning.
It seems to complicate things.

Bye,

a.

@atux The OSC data you get from Iannix (on port 57120?) includes the curves.
separating them from the other data depends on whether you are using the MrPeach library so [route /curve] or for vanilla [oscparse] >>> [route curve]
[route /curve /trigger] or [route curve trigger] will give you both curves and triggers.
You will probably need the transport messages too so as to stop playback when you stop playback in iannix so [route curve trigger transport]

Then unpack the curve data [unpack s f f f f f f] and I think the 2nd 3rd and 4th outlets are xyz.
Actually you will probably need a timer in Pd...... "I have not received a coordinate in x mseconds >> stop sound" to kill the glissando when the curve ends.

Maybe you have to tell iannix to send the curve data....... I can't remember.
David.

@jameslo said:

@Bangflip Can you please post your noisy data so I can try a different smoothing algorithm on it? I'm porting something from the Arduino world for fun.

Yes, I deleted already my old data, but recorded this curve today, that you can use it. It's an strange curve.

I got this curve by send the pitchbend Data from Pure Data to Cubase and record as automation. All values linear via Mackie Mode. Then I switched Cubase to "Houston" Mode and recorded the the output of cubase with pd into the array. The result is always the same. I thought it has maybe to do with the 20 years old algorithm for my houston hardware. Because if I send the midi data via mackie mode to pd, it's much smoother, without these artefacts.

The curve you can see here is also a little bit different in what I described after starting this thread, because the artefacts are in the opposite direction. But it's clear to see with the eyes, how the curve should be. Would be cool, if you could also post, what you came up with. I am interested in the result.

For Forum Request.pd

@Bangflip I would start by making a patch that takes a lower and upper index such that curve[lower] < curve[upper]. That patch would perform the interpolation you described to substitute for the negative portions of the raw curve, and if the indexes are adjacent then it would just output the adjacent curve values. You can test that patch until you are convinced it's working. Then your problem is mostly reduced to finding all the lower and upper index pairs, with one special case if the largest curve value isn't at the end of the input table.

The (lower, upper) pairs for your example are (0,1) (1,4) (4,5) (5,6) (6,8) (8,9) and (9,10)

I tried using [lop~] but the problem is that its beginning state is always 0, which may or may not be what you want. Also, lop~ may allow some negative slope to pass through, which I'm gathering you don't want.

Here's a Pd-vanilla version of a linear-to-curved range mapping formula from SuperCollider. Published at https://github.com/jamshark70/hjh-abs . There's a message-rate and signal-rate version.

(Helpfile typo has been fixed but I won't bother to upload a new screenshot.)

This is, of course, close to cyclone's [scale]. It's close -- the symmetry is different (help file says "better" but actually that's a matter of taste, or situational need). For reciprocal values of [scale]'s "exponential" factor, the respective curves seem to be a reflection around the diagonal (x <--> y); for negated values of [lincurve]'s curve factor, one curve is a 180-degree rotation of the other (x --> -x and y --> -y). Compare -7 vs +7 lincurve against 0.2 vs 5.0 scale:

-7 curve, ~0.2 exp:

+7 curve, ~5.0 exp (lincurve and scale are very very close here!):

hjh

Amplitude modulation of any sort, including envelopes, always distorts the spectrum to some extent.

Normally we don't notice because typical sounds have a complex spectrum, which masks the distortion.

But here, you are applying it to an artificially simple spectrum, containing only DC offset. DC offset is silent, and the spectral distortion is not, so there is nothing to cover it.

I generated an audio file with a 30 ms ramp up and 50 ms ramp down. For comparison, I applied this envelope to a sine wave in the right channel. Then I opened this file in Audacity and looked at the spectrogram.

I think it's pretty easy to see here why the envelope might be audible in the case of DC * envelope, but not perceptible in the case of the audible signal * envelope.

Bottom line is, just because you hear spectral distortion in an artificial scenario which you would never encounter with audible signals, doesn't mean that it will be noticeable in real world scenarios.

(Carrying it further: If there is no envelope, there's a risk of an instantaneous transition from non-zero to zero or vice versa. Instantaneous transitions require a lot of high-frequency content, which we hear as a click. A linear transition effectively lowpass-filters the instantaneous transition -- there are still artifacts, but they are relatively low amplitude, and in a frequency range normally occupied by musical tones at a much higher amplitude. A ramp-enveloped sound will never be perfect, but it's better than a rectangular envelope.)

"replaced by something better" -- A sinusoidal envelope shows a smoother spectrogram. You might try that: cos * 0.5 + 0.5 -- from pi to 2pi is your ramp up, 0 to pi is the ramp down.

Edit: You can eliminate the +0.5 by squaring the cos and halving theta, because cos^2 x = cos(2x) * 0.5 + 0.5. Actually cos~, IIRC, scales radians down to 0 .. 1, so you could do line~ --> cos~ --> [*~] (cos~ to both inlets) and drive it by "0.25, 0.5 30" for the ramp up, and "0, 0.25 50" for the ramp down. Haven't verified this at the computer but I think it's right.

hjh

@avpd The maths is written at the beginning of the source file for [curve~]....... curve~.txt

Also take a look at this (for vanilla)....... https://forum.pdpatchrepo.info/topic/12145/curvegen-curved-ramp-generator-for-pd-vanilla .....
Download the patches from the link and they should furnish some clues for your patch if the mmb original external used the same factor values as cyclone.
David.

@jameslo I didn't actually go through the code but just in the simple tests I did if you create the entirety of the graph with the [receive~] (including the [receive~]) before the graph with the [send~] (including the [send~]) then it appears to be in the right sort-order.

however when I deleted the [send~] and [receive~] afterwards I couldn't get it back in the right order when I recreated them no matter the order.. maybe something to do with [send~] being at the bottom of a graph and [receive~] being at the top of one or something.

might have a look through the source later and try to figure it out for real.
I would think that this is dependent on the implementation and not guaranteed to stay the same if the implementation changes significantly tho..
Ideally all [send~] graphs would be sorted before their corresponding [receive~] graphs..

@jameslo i haven't tested it but it might be the case that if you make sure to create [receive~] after [send~] that there will be no latency, (unless the [receive~] is in part of the graph that leads to [send~]). You might have to create the entire graph the [recieve~] is part of after creating the entire graph the [send~] is part of, I'm not sure..

edit: after testing I was not able to get that to work
edit2: after further testing it seems like if I create the graph with the [receive~] first it gets sorted last, but not if I delete the [receive~] and recreate it afterwards

so there isn't always latency, it depends on how the dsp graph is sorted. If the [recieve~] is sorted earlier in the graph before the [send~], as in the case of feedback, then there will be a block delay since [recieve~] will process the shared buffer's samples before [send~] has had a chance to write to the shared buffer. (so [recieve~] will only get the samples written in the current block by [send~] in the next block, creating a block delay.)

NoxSiren is a modular synthesizer system where the punishment of failure is the beginning of a new invention.

--DOWNLOAD-- NoxSiren for :

• Pure Data :
  NoxSiren v15.rar
  NoxSiren v14.rar

• Purr Data :
  NoxSiren v15.rar
  NoxSiren v14.rar

--DOWNLOAD-- ORCA for :

• x64, OSX, Linux :
  https://hundredrabbits.itch.io/orca

In order to connect NoxSiren system to ORCA system you also need a virtual loopback MIDI-ports:

--DOWNLOAD-- loopMIDI for :

• Windows 7 up to Windows 10, 32 and 64 bit :
  https://www.tobias-erichsen.de/software/loopmidi.html

#-= Cyber Notes [v15] =-#

• added BORG-IMPLANT module.
• introduction to special modules.
• more system testing.

#-= Special Modules [v15] =-#

• BORG-IMPLANT (connects ORCA MIDI system to NoxSiren system)

#-= Current Modules [v15] =-#

• VCO (voltage-controlled-oscillator)
• VCO2 (advance voltage-controlled-oscillator)
• WAVEBANK (additive synthesis oscillator)
• ADSR (Attack-Decay-Sustain-Release envelope)
• C-ADSR (Curved Attack-Decay-Sustain-Release envelope)
• CICADAS (128 steps-Euclidean rhythm generator)
• CICADAS-2 (advance 128-steps polymorphic-Euclidean rhythm generator)
• COMPRESSOR (lookahead mono compressor unit)
• DUAL-COMPRESSOR (2-channel lookahead mono compressor unit)
• STEREO-COMPRESSOR (lookahead stereo compressor unit)
• MONO-KEYS (virtual 1-voice monophonic MIDI keyboard)
• POLY-KEYS-2 (virtual 2-voice polyphonic MIDI keyboard)
• POLY-KEYS-3 (virtual 3-voice polyphonic MIDI keyboard)
• POLY-KEYS-4 (virtual 4-voice polyphonic MIDI keyboard)
• POLY-KEYS-5 (virtual 5-voice polyphonic MIDI keyboard)
• POLY-KEYS-6 (virtual 6-voice polyphonic MIDI keyboard)
• BATTERY (simple manual triggered machine for drumming.)
• REVERB (reverb unit with lowpass control)
• STEREO-REVERB (stereo reverb unit with lowpass control)
• RESIN (advanced rain effect/texture generator)
• NOISE (generates black,brown,red and orange noise)
• NOISE2 (generates yellow,blue,pink and white noise)
• COBALT (6-stage polyrhythm generator)
• SHAPER (basic shaper unit)
• FOLDER (basic wave folding unit)
• STEREO-FOLDER (stereo wave folding unit)
• DUAL-FOLDER (advance wave folding unit)
• POLARIZER (transform a signal into bi-polar, uni-polar, inverted or inverted uni-polar form)
• CLOCK (generates a BPM clock signal for sequencing other modules)
• CLOCKDIVIDER (a clock divider with even division of clock signal)
• CLOCKDIVIDER2 (a clock divider with odd division of clock signal)
• DELAY-UNIT (delay unit)
• STEREO-DELAY (stereo delay unit)
• CHORUS (chorus unit)
• STEREO-CHORUS (stereo chorus unit)
• SEQ (advance 16-step/trigger sequencer)
• KICK (synthesize kick unit)
• KICK2 (synthesize flavor of KICK module)
• KICK3 (synthesize flavor of KICK module)
• SNARE (synthesize snare unit)
• CLAP (synthesize clap unit)
• CYMBAL (synthesize cymbal unit)
• RAND (RNG generator for other modules parameters)
• FMOD (feedback modulation unit)
• AM (amplitude modulation unit)
• RM (ring modulation unit)
• LFO (low-frequency-oscillator)
• LFO2 (advance low-frequency-oscillator)
• COMBINATOR (combine two waves)
• COMBINATOR2 (combine three waves)
• COMBINATOR3 (combine four waves)
• STRING (Karplus-Strong string synthesis unit)
• STRING2 (advance Karplus-Strong string synthesis unit)
• DETUNER (parametric 4-channel detuner unit)
• CRUSHER (basic audio resolution unit)
• STEREO-CRUSHER (basic stereo audio resolution unit)
• DUAL-CRUSHER (advance audio resolution unit)
• FILTER (basic filter)
• VCF (voltage-controlled-filter)
• MAR (Moog-analog-resonant filter)
• VCA (voltage-controlled-amplifier)
• DUAL-VCA (advance voltage-controlled-amplifier)
• FMUX (multiplexer with fast A/D internal envelope)
• MMUX (multiplexer with medium A/D internal envelope)
• SMUX (multiplexer with slow A/D internal envelope)
• FDMX (demultiplexer with fast A/D internal envelope)
• MDMX (demultiplexer with medium A/D internal envelope)
• SDMX (demultiplexer with slow A/D internal envelope)
• MIXER (mix 1-4 possible waves)
• SCOPE (oscilloscope analyzer)
• MASTER (fancy DAC~)
• BOX (useless decorative module)

NoxSiren integrated modules menu system.