PD/pduino patch not allowing comport to work no matter what
So I recently wanted to try connecting arduino (a potentiometer) to PD to control a slider. One of the main objects I have been seeing everyone use is the "comport" object. A week or so in and I cannot seem to call upon the abstraction "comport" and it also does not show up in my "Find externals" search results n my Help section of the PD window. However, I have tried to download the comport extension and placing it (within folders as well as directly) into the patches I am trying to work with but with no luck.
Some of the possible problems could be that its not the right pure data version (I heard it might work with extended? Not even sure what version mine is or how to check) or old version of the "Find externals" plug in (by Deken?). Or perhaps I am placing the comport abstraction in the wrong places (I have also tried placing it in the externals sub directory).
Sorry for t the long message. Any help would be amazing. THank you!
Kor'in - Advance 6-voice polyphonic synthesizer made with NoxSiren [v4.0]
Kor'in an advance example of how to create an entire synthesizer using only NoxSiren [v4.0] system. This is non-standard subtractive synthesizer model but can be modified into a hybrid complex model.
What is NoxSiren system ?? <--
https://forum.pdpatchrepo.info/topic/13122/noxsiren-modular-synthesizer-system-v4-0
Kor'in Download :
Kor'in.rar
-Kor'in Structure-
- Kor'in birds eye view
- Kor'in voice unit
- Kor'in delay unit
- Kor'in noise unit
- Kor'in SMU unit
Smooth frequency transition
you should use a logarithmic line~ object to adjust the curve as smooth as you want.
On top of that you should apply a Nyquist correction to the output of your oscillator abstraction.
So here you have some imagines how to do that. The Nyquist abstraction is used in the output of the triangle oscillator abstraction as an example. Then the final output can be controlled with a logarithmic line~ object.
OBS : If you need more then one oscillator you can apply this for each oscillator and then use a mixer and then the output of the mixer you use again the same idea. In this way you have an oscillator smooth stage control and a final mixer stage control for extra smoothness.
This is just the simple mono smooth control (no curve adjustment)
The same idea but as a stereo version
Here is with logarithmic smooth control (with curve adjustment)
Here you have a Nyquist correction abstraction
Here you have a triangle oscillator with Nyquist correction
You can also download xline~ which is an object that is doing just that :
https://forum.pdpatchrepo.info/topic/13084/xline-logarithmic-line-object
Nek'Sum - An advanced drone/texture monophonic synthesizer <- [v6.0] + // Mandarin Edition //
Nek'Sum-6 drone/texture monophonic synthesizer is compose of 5 stages :
First stage -> 3 main OSC with noise mixer option and generative synthesis support with 5 types of waves (tri,sqr,saw,supersaw,generative).
Second stage -> Filter stage with morph option and 4 filters types : Pass through, Lowpass, Highpass, Bandpass for the first stage.
Third stage -> 3 LFO (sin,tri,sqr,saw) modulators for the second stage.
Forth stage -> 3 Phasor's for the third stage.
Fifth stage -> 1 Deep Reverb with Lowpass filter for the forth stage.
It is capable of generating a large soundscape of drone/texture sounds inspired by The Doctor.
-UPDATE-
Thanks to Seven of Nine Nek'Sum is now at version [v6.0]
- Added Mandarin edition after cyber-brainstorming with Jade Chia-Jung [v6.0].
- Translation of the Ancient Egyption logo into obscure dialect of Anquietas language, thanks to Daniel Jackson [v6.0].
- Thanks to Nox cyberart society now the GUI is much better [v5.0].
- Added reset, randomization and resize for the generative synthesis [v5.0].
- Added generative synthesis support for each oscillator [v4.0].
- Added a noise mixer with 4 types of noise for each oscillator (orange,yellow,blue,pink) [v3.0].
- Added a morphing mechanism for filter stage [v3.0].
- This new version has a better GUI interface powered by a Borg-Casimir engine [v2.0].
-CYBERLOG-
Project manager : Oma Desala
Programming/UX design : Boran Robert Andrei
QA engineer : Anubis
Generative synthesis system design/Lead engineer : Seven of Nine
DSP engineering : Jade Chia-Jung, The Doctor
Testing/debugging system engineer : Lt. Colonel Samantha Carter
Language consultant : Daniel Jackson
Patch Download English Edition :
Nek'Sum 6.rar
Nek'Sum 5.rar
Nek'Sum 4.rar
Nek'Sum 3.rar
Nek'Sum2.rar
Nek'Sum.zip
Patch Download Mandarin Edition :
Nek'Sum 6 - Mandarin Edition.rar
Mandarin special edition :
Snapshots :
RMS vs FFT complex magnitudes
I'm up to the beginning of Katja V's Fourier Transform section and I've already found a few answers to my questions. I also managed to get the sum of FFT term amplitudes to match the RMS value for arbitrary input. Here's the patch:
Inside [pd computerMagnitudes]:
compareTimeFreqAmpl2.pd
All the things on the left are just tools to fill the input table, but you can also just draw. Once you have your signal, bang computeMagnitudes to measure its amplitude both ways.
I made a couple of simplifications that not only got the test working but also gave me more confidence that I was comparing apples to apples:
- I'm computing RMS and the FFT from a single static 1024 vector, so I'm now comparing two views of the exact same signal and there's no need for averaging.
- I learned from Katja that if you perform a complex FFT on a real signal, you don't have to worry about which terms to double because the FFT gives you those terms's double in the upper half of the output explicitly. The real FFT skips the upper half for efficiency because it's related to the lower half.
- I also learned that even the cosine and sine components of each harmonic are uncorrelated signals, so I now sum their magnitudes individually across all harmonics. There's no need to compute the magnitude of each FFT term first.
So I think the issue I was having with noise was just an artifact of a badly programmed test, probably having to do with the way I was averaging term magnitudes, but I don't really know.
7/18/2020 update: I've found info in Katja's blog that suggests that this patch is wrong (or maybe even not possible). Exhibit A:
IMHO, this contradicts what she spent so much effort establishing on the prior two pages (http://www.katjaas.nl/sinusoids2/sinusoids2.html
http://www.katjaas.nl/correlation/correlation.html), that the cos and sine components of all FFT terms are orthogonal. If they're orthogonal, how could they cancel each other out?
She raises a another point on the FFT output page that really makes me wonder why my patch seems to work:
In this case I agree--Fourier coefficents are really the peak amplitudes of the cos and sine components--but my confusion over this is what made me program the patch the way that I did. So why is it working?
[text sequence] access wait times in 'auto' mode?
@whale-av Ah, right -- I didn't explain clearly. So maybe it's time to "begin at the beginning."
Where I'm coming from: In SuperCollider, it's easy to express the idea of an event now, with a duration of 100 ms (time until the next event), with the gate open for the first 40% of that time:
(midinote: 60, dur: 0.1, legato: 0.4)
... producing control messages (0.04 is indeed 40% of 0.1 sec):
[ 0.0, [ 9, default, 1000, 0, 1, out, 0, freq, 261.6255653006, amp, 0.1, pan, 0.0 ] ]
[ 0.04, [ 15, 1000, gate, 0 ] ]
That is, an event is conceived as a span of time, with the action occurring at the beginning of the time span.
By contrast:
reset: line 0
reset: bang
w: 100
What is the data point that should occur at the beginning of this 100 ms span?
OK, never mind, continuing...
bang: bang
d: 60
w: 200
Ohhhh... it's really 200 ms for midinote 60. But you didn't know that at the time the data came out of the left outlet. Normally we assume right to left, but at the moment of requesting the next data from the sequencer, it's actually left to right.
bang: bang
d: 62
w: 300
bang: bang
d: 64
And... (the really unfortunate flaw in this design) -- how long is 64's time span? You... don't know. It's undefined. (You can add a duration without a data value at the end -- and I'll do that for the rest of the examples -- but... I'm going to have to explain this to students in a couple of days... if there are any clever ones in the lot, they will ask "Why is this note's duration on the next line? Why do we need an extra line?")
Let's try packing them:
reset: line 0
reset: bang
bang: bang
notedur: 60 100
bang: bang
notedur: 62 200
bang: bang
notedur: 64 300
bang: bang
notedur: 64 400 (this is with "400;" at the end of the seq)
bang: bang
Now, that "looks" like what I said I wanted -- but it's misleading, because the actual amount of time between 60 100
and 62 200
is 200 ms. The notes will be too short.
reset: line 0
reset: bang
notedur: 64 100 -- "64" is leftover data
bang: bang
notedur: 60 200 -- OK, matches sound
bang: bang
notedur: 62 300 -- OK
bang: bang
notedur: 64 400 -- OK
bang: bang
So the last version is closer -- just needs a little logic to suppress the first output (which I did in the abstraction).
Then, to run it as a sequence, it just needs [t b f f] coming from the wait outlet, and one of the f's goes to [delay] --> [s go]. So the completed 40% patch (minus first-row suppression) looks like this:
I guess part of my point is that it took me almost two hours to work this out yesterday... but sequencing is a basic function of any music environment... isn't there some way to make it simpler to handle the very common musical conception of a note with a (subsequent) duration? (Pd already has exactly that conception -- [makenote] -- so, why is the sequencer at odds with [makenote]?)
hjh
Best way to create random seed on [loadbang] with vanilla?
A while a ago i was thinking about a classical system to create random numbers. The idea was to fuse PI-calculus with fuzzy type I in a network system where you can exchange fuzzy type I sets. So the network could output a fuzzy set that could have some specific random properties. I manage to fuse them together but i was still not satisfied by the idea. Now i think that by changing the fuzzy type I to type II together with PI-calculus you can make something like a random number. The monadic-PI-calculus is just for normal fuzzy sets. The Polyadic-PI calculus is a higher order where you can send fuzzy sets of sets over the network.