As for debouncing, you will most likely with any real-world switch. You could try to limit it in the analog domain by adding a capacitor, however you may well do that from within Pd. I have an example debouncer just here: https://github.com/BelaPlatform/Bela/blob/topic/salt-core-merge/examples/13-Salt/DuoWave/debounce.pd
Hi,
Finally found some Bela time..
I have adapted and changed the patch - debounce is definitely necessary.
However it does not seem to work, the debounce, in my frankenpd.
The Pure Data patch here is clumsy, apologies - a friend of mine will give me a hand with the inlets & outlets.
One step at a time..
Update *
There was a physical problem with digital 13
The debounce works only for 13 - I don't understand why it should not work for 14 and 15 :-/
Button 13 pressed once
Button 14 pressed once
Button 15 pressed once
Thanks!
W
Dear Forum, you seem to be my proverbial duck.
This is my last Pure Data Patch - I think the debounce does not work because of variable conflicts and my poor Pure Data Patching talent..
https://cloud.constantvzw.org/s/nxW6TiBb6cpiGd8
My 2 cents - your opinion?
Thanks
dywen
Well your problem there is that you are printing the raw values as opposed to the debounced values.
Also, you may want to read about dollar-sign variables in Pd, e.g.: http://write.flossmanuals.net/pure-data/dollar-signs/
They represent the arguments passed to the current patch when loaded as an abstraction, e.g.: $1 is the first argument, $2 is the second argument and so on. So unless you load this patch as an abstraction inside another patch, then they do not make much sense and they are all initialized to zero.
giuliomoro
Hey,
I think/hope I took all your remarks to heart - but the buttons (2&3) still bounce in all directions. Button 1 behaves.
---> new patch with abstractions (after 10 years, I think I understand them now - Pd has it's own universe of logic)
https://cloud.constantvzw.org/s/ymSwHcgyAgcfPWG
The float message that comes from the output of the [spigot] and goes into the [delay] is changing the delay time. It gets me every time. I fixed my patch online: https://github.com/BelaPlatform/Bela/blob/topic/salt-core-merge/examples/13-Salt/DuoWave/debounce.pd
Aha - I thought it was my mistake - as Pure Data and me are getting slowly reacquainted.
Thanks!
--> With the changes, the bouncy behaviour was still there - until I increased the delay in the debounce subpatch.
From 8 milliseconds to 80 (still quite a small amount)
As it only regards the button and not the audio - this does not seem like a problem.
Two other "issues" arise:
- Button 3 still gives me 2 blocks dropped - is this a problem?
button 3: 1
Underrun detected: 2 blocks dropped
button 3: 0
dywen - Button 3 still gives me 2 blocks dropped - is this a problem?
Check out the help file for [readsf~]:
You must open the soundfile in advance (a couple of seconds before you'll need it)
using the "open" message. The object immediately starts reading from the file,
but output will only appear after you send a "1" to start playback. A "0" stops it.in this case you are sending the [open( and [1( messages at the same logical time, so the object starts reading from disk immediately once it receives [open(, but by the time [1( comes in, it has not buffered enough data to be able to start the play back, therefore it has to sit and wait for the data to be read. I'd suggest you send the [open( message to [readsf~] immediately after stopping the recording.
dywen Pushing the play button only works when I press the button (I have to keep it pressed)
If you want to use the button as a toggle (click goes to 1 ... click goes to 0), then you need something like
[select 1]
|
[ ] <<< a toggle
|
[readsf~]something similar is implemented here.
Aha, ok
Again Pure data guts & mechanics - [readsf~] does not complain when I use keyboard keys - but the data rates are not the same, I imagine.
I actually don't want the button to work as a toggle (because that means you have to push it twice - counter intuitive for my "public")
I just don't want the zero immediately after the one
-- Press Button3 = 1 -> play file till the end if nothing else happens
-- at the end of playing the file zero comes (it seems necessary that the state really changes to zero - it's not automatic?)
-- When the Button is pushed while the file is still playing, it begins playing at the beginning
(which does imply a zero first and then 1)
Hope you are still following..
dywen Again Pure data guts & mechanics - [readsf~] does not complain when I use keyboard keys - but the data rates are not the same, I imagine.
Well, Pd on the desktop does not notify you of dropouts. It also works with larger block sizes, extra buffering and faster CPUs, so it may well make it just on time some times, but it is not a behaviour to be relied upon.
dywen A -- Press Button3 = 1 -> play file till the end if nothing else happens
-- at the end of playing the file zero comes (it seems necessary that the state really changes to zero - it's not automatic?)
A simple design would be:
[debouncer]
|
[select 1]
|
[0, 1(
|
[readsf~]So that you always send a 0 before a 1. However this would have the same problem as above: you always need a [open( in advance of sending a [1(.
Actually, you may want to use [readsf~] to fill in an array the first time you read the file, so that you can then keep reading from the table. In hindsight, if all you care about is recording and playing back a sample, why don't you write straight into an array instead of going to disk?
Hey,
Now I have broken playback completely - tss tss
https://cloud.constantvzw.org/s/LjfYjzwsrym25cY
I actually started out with arrays, because I want a 10 second recording or less - good for arrays.
But I got help from a friend of mine who knows pd and he proposed me write and readsf. I followed, because it did what I wanted it to do.
Unfortunately a different job is calling me now and I only have a little bit of time tonight to further look into this. After that I have to stop working on this project because of work. Meh!
Thanks a lot for following through!
Dywen
Hi,
After tackling Touch & MPR121 - thanks for following up on that one - I now come back to using the buttons and digital in for recording. The IDE has no problem with Pure Data 5 second arrays anymore - Great!
I grafted the digital in objects onto the working code of MPR121 and it doesn't stick.
There must be a logical error somewhere:::
The terminal stays totally quiet :-/
Any ideas/suggestions?
Thanks!
Dywen
I think you need [in 11, in 12( instead of [in 11 12(
Yes!!!
tss tss - It's swelteringly hot in Belgium - continuous brainmeltdown..
Cooooool - this makes my weekend and all code/patches are working for this project :-)
(buttons will record - touch will play)
I wish you a pleasant weekend!
dywen