PIR+ARDUINO+PDUINO
@je Welcome to the forum...!
I have changed very little, and tidied a bit....... this.zip
I have...
Put the fader range as 0 to 1.
Added some routing so that only button 2 starts the track, and connected that to the [open...( message.
I don't have an Arduino, so will not be much help on how to "connect" the PIR to button 2....... but I think you need to use the [comport] object or the [pduino] object for Pd to communicate with the Arduino.
Also there was a long time ago a test patch for the arduino....... https://forum.pdpatchrepo.info/topic/12362/pduino-problem/3 but a lot of objects will have changed as you will see in the thread.
However, there are some real Arduino/Linux experts on the forum who will help you.... such as @alexandros
David.
Did random seed change?
@seb-harmonik.ar said:
The rationale is that the behavior of a patch SHOULD be completely reproducible if desired (and that's the intent).
@jameslo said:
How could you reproduce them (in order to study them) if the pseudo-random number sequence wasn't deterministic?
There might be exceptions, but in every pseudorandom number generator I've ever heard of, the sequence does repeat, provided that it's been seeded with a consistent value first.
SuperCollider seeds the random number generator at startup based on some value calculated from the system time. If you want replicable behavior, you do thisThread.randSeed = /* some value explicitly under your control */
at the moment of your choosing.
Pd [random] does implement a "seed xxx" message, so it isn't correct to suggest that Pd's constant initial seed is the way to get a replicable sequence. That's lucky if that's what you want, but it isn't necessary, and it may not be ideal either.
The problem with the counterargument here is that the [random] behavior depends on factors outside the user's direct control. If you really want a replicable sequence, the way to be certain of that is to send a "seed xxx" message to the random number generator at a moment that is under your control. Otherwise, you have no control over other components that might be pinging the random number generator. (Suppose, for instance, your patch depends on an abstraction which pings a [random] from a [loadbang]. Then, later, the abstraction author thinks, no, I shouldn't do that, I should get that first random value only on demand. Then you move your patch to another machine, re-download the abstraction from its source, and bang the behavior is different.) edit: that's a bad example, never mind.
Viewed from that perspective, one could say that the current Pd behavior misled the OP to believe that it wouldn't be necessary or desirable to control the seed... and then something changed somewhere in the system. That's actually quite a bad situation -- OP relied on happenstance for a mission-critical sequence of notes, and it isn't clear how to recover the original behavior.
Now this part is interesting, from whale-av: "There seems to be a shift......... the 2nd 3rd 4th etc. created are the same as the 1st 2nd 3rd etc. used to be." One possible explanation could be that, in the old version, something was consuming one random value before the user patch did (so the user patch never saw the true first value) -- so in the old system, the "first" random value would have been the second to be generated. Then, in the later case, the first value to be seen is the real first value. (But that might be -- or, is probably -- something in the test scenario and not in Pd itself.)
hjh
phase index of an oscillator and 1 sample delay in pd?
@KMETE
the Max patch looks like feedback-FM to me. For PM the + would be placed between phasor and circle, if I'm not mistaken.
And with 1000 ms delay, as I read the Max patch? there would be no need for 1 sample-blocks.
A thread on this topic:
https://forum.pdpatchrepo.info/topic/6185/feedback-fm-algorithm
DC-blocking you can do with [hip~ 20] for example (I'd put it in the feedback-loop).
cycle object
[cos~] ? Is a cosine-tabel, to get a sine you can drive it like this:
[phasor~]
|
[-~ 0.25]
|
[cos~]
Offtopic: Pd's cosine has a slight DC-offset.
https://forum.pdpatchrepo.info/topic/13709/bug-osc-cos-circle-asymmetry-drifting-out-of-phase
@alexandros said:
Creating a one-sample delay is achieved by placing your objects in a subpatch and putting a
[block~ 1]
object in there. Then you have to use[tabsend~]
and[tabreceive~]
instead of[delwrite~]
and[delread~]
to achieve the one-sample delay.
Yes. And be aware of the importance of creating [tabsend~] beforehand of [tabreceive~] . You can read about in the Pd documentation 3.audio.example > G05.execution.order.pd
For feedback, I usually build subpatches with such a dummy-connection, save the patch, and delete the dummy cable lastly and save again, for perceving the execution order and avoiding a dsp-loop.
[delwrite~] and [delread~] can become as short as 1 sample, too.
In both [osc~] and [phasor~], the phase is set by control messages, but since you'll have a one-sample block size, that shouldn't be a problem, you can just set the phase to what ever you like and it will be reset at the next sample block (one sample later).
This is one of the biggest myths in Pd (at least for me), but unfortunately not true. (Vanilla 52.2)
See vphasor~-help : https://github.com/dotmmb/mmb
Still the same, if you put it in a subpatch with [block~ 1].
Documentation is lacking here. There are very few timing- sample- or phase-critical control-objects that are able to update (sub-)sample-accurately in-between block-boundaries of 64 samples minimum:
I only know of [bang~], [metro], [delay], [pipe], [vline~]
Convert analog reading of a microphone back into sound
hey @whale-av @manuels @jameslo thanks once again for the feedback! I think we are getting there, very exciting. I just quickly plugged your suggestion into my patches and they both work well. Interestingly enough now the sig~ and the resampling method result in two sounds that are timbrically quite different, but still coherent with what I would expect. This is super interesting, even as a creative toolset, as long as the difference in timbre are not artefacts. I will investigate this further and try to post some audio examples.
Gonna work more on the project this week and keep you posted. Just bear with me as I cannot work on this full-on every day like the past weekend, cause of other commitments.
@jameslo sorry to hear, it is quite jumping around these days, I hope your symptoms are bearable, and I'm glad that an interesting problem can help a little
@whale-av the vline~ there is very elegant! I had previously tried with a line3 in the control domain but your suggestions makes more sense. I've used a bucket object to get the interval, that should be the same as what you are doing in your patch.
@manuels yes, indeed. Different filters are the next thing I'm gonna look into, especially as I gonna need a more systematic spectral analysis of the resulting sound to make sure it is still coherent with the expected signal.
Do you know how to dynamically write the function to an [expr]?
Thank you, @Jona and @whale-av for the pointers.
Yes. I want to be able to change the operators, etc. . So for instance the multiply in [expr $f1*$f2] to a plus while the Gem stream is running.
Two options I have tried are assembling an expr clone with all of its operators as type-selectable by idx, so an expr router of sorts. Where one could assemble the pieces by list(functypeID#) and variables. But that fails because it's just too clumsy.
The option below is the best, I've come up with so far.
And if, as you say whale-av, the expr itself is written at runtime (until the feature gets added sometime in the future ) probably the best way to go.
Should say something, I learned there is no way to pass it in as a symbol [expr $1`], where $1 is a creationarg symbol because expr interprets it as a desire to create an array.
One option may be using iemguts and dynamic patching. If I look into it, will try and let you know what I find out.
Seems sending it a list is something that should be added.
Would help a lot for patches where dynamically changing formulas in real-time streams (like a GEM or ~) best suit their design.
Thanks, again, @jona and @whale-av. Really appreciate your response and the timeliness with which you replied,
Happy PD-ing.
Here's the way I will probably go with: Popping the subwindow where all the expressions are then closing it when I'm done,
Controlling Pd from another programme
@Worik Not sure what you are looking for.....
If you want to open a patch from the command line you can open Pd and a patch with a batch file...... in windows it would look something like this....
"C:\Program Files (x86)\pd\bin\pd.com" -path C:\Users\David\Desktop\PDMusic\Minx -path C:\Program_Files_(x86)\pd\extra\readanysf~\ -r 44100 -asio -nomidi -audioindev 20 -audiooutdev 15 -inchannels 32 -outchannels 22 -audiobuf 2 -blocksize 64 -callback -nosleep -open Minx_Run.pd
exit`
which on my system opens Minx_run.Pd and tells Pd where to find it........ \PdMusic\Minx
It also sets a load of command line switches...... to set up audio for this very specific instance (useful!).
There will be similar methods in other os's.
When you want to close the patch (and Pd) you kill the Dos window that the batch file created.
Messages can be sent to Pd to close a specific patch..... but another patch will have to be open (probably the one receiving the message) or Pd will terminate.
It can be done from within the patch but its complicated........ https://forum.pdpatchrepo.info/topic/11710/closing-patches-without-pd-crashing-hopefully-in-an-elegant-way ...... and not easy.
If you want to keep Pd open and control from another program........ then as @seb-harmonik.ar describes........ but the menuclose message might crash Pd if another patch (any patch) is not open........ https://forum.pdpatchrepo.info/topic/4063/close-patch-window-command-object
Anyway, it is cleaner to use a second patch to receive your messages and close the desired patch.
David.
Andy Farnell sequencer example doesn't work
@vitaliistep His patch works for me....... farnell.pd ...
You must have connected the outlet of [f] to the inlet of [+ 1] after connecting it to [select].
Then the message [0( to reset the counter is overwritten by the next value from [f] and the counter runs past the reset......... https://forum.pdpatchrepo.info/topic/13320/welcome-to-the-forum
David.
It is a very common problem when building a patch from a screenshot.... and not your fault...
You can put a [trigger] [t f f] after the [f] to ensure the correct order....
Is this a bug?
@Bangflip Sort of...... but we are not allowed to call it that.
Messages that start with a float (number) and have more items than one are automatically treated as lists.
But if the first item is text then it is dropped by a [$1 $2 etc.( message, and that puts your $3 out of range.
You can fix that by setting the message explicitly as a list.....
[list two 1 3( will work.
When a message starts with a "text" that text is treated as a selector for routing the rest of the list.
But list is also a selector..... it gets complicated.
We cannot call it a bug because the selector processing is so fundamental to almost every patch ever made that it cannot be changed...... patches made prior to such a massive change would be broken.
There is a thread about it here....... https://forum.pdpatchrepo.info/topic/13636/route-asymbol-doesn-t-match-tagged-symbols
The thread includes some example patches.
"list" has issues too though.
And things get worse when using [route] and [select].
........... pd-selector.pd
Also, if you are (might be?) unsure about global and local variables in Pd ($ dollars) then read this...... https://forum.pdpatchrepo.info/topic/9774/pure-data-noob/4
And make sure you understand the order of operations........ https://forum.pdpatchrepo.info/topic/13320/welcome-to-the-forum
David.
How do band splitters work?
@schitz
The difference of a modified signal to it's dry one is the opposite:
LP-Original=-HP
Original-BP=Notch
Dry-Notch=BP
....
see this post:
https://forum.pdpatchrepo.info/topic/13409/how-can-i-create-a-switchable-filter/4
If I'm not mistaken, using a Butterwoth filter instead, makes a quick and dirty digital Linkwitz-Riley-Filter https://en.wikipedia.org/wiki/Linkwitz–Riley_filter
[years later EDIT: Also see this patch: https://forum.pdpatchrepo.info/topic/7006/multiband-compressor/5 ]
@schitz said:
close to the original as possible
@whale-av said:
phase correlation
That's the difficult part:
I would love to have a chat and see examples of linear-phase
and minimal-phase filters in Pd!
anyone ported this to Pd yet?
2 speakers
would make the topic infinitely complicated, as different positions and responses of the speakers come into play.
WebMidiMarkov
I worked on the Emscripten / OF webMidi implementation, and made a patch.
First time I made the Emscripten / Pure Data stuff without ofxOfelia, but only with OF and ofxPd.
Its with the mscale and markov abstraction that is also from @ingox and @weightless.
https://forum.pdpatchrepo.info/topic/11722/mscale-transpose-notes-according-to-given-scale-and-root
https://forum.pdpatchrepo.info/topic/12147/midi-into-seq-and-markov-chains
Connect a midi keyboard to the website, create a markov chain and connect the website to a sound device (with midi).
Works not with Firefox and Safari, because they didnt implement webMidi...