Hi,

  • Yesss, my Bela Mini got delivered yesterday!! *

For a few years now I have been working with Arduino and Frankenscripts (copy pasted and sewn together) that do what I want.
Linux user, poor coder..

I dipped my toes into Pure Data more than ten years ago and I need a hand to link the physical computing universe of Bela to the existing knowledge I have. Brain hurts. Need Forum oil/boost/mushroom..

Current simple wish:
- pushbutton0 on digitalIn3 records sound from the microphone plugged into the line in
- pushbutton2 on digitalIn4 stops recording
- pushbutton3 on digitalIn5 plays sound

I have a Pure Data Patch that works on my computer, with keys from the keyboard.
Here: https://cloud.constantvzw.org/s/EcsZzoNte8k54xQ
alt text

I want to replace these keys with pushbuttons & Bela - but I have a hard time figuring out what the Patch needs (have read the Pure Data Digital and Getting Started multiple times).
- For example, I try to make the link with Arduino's baud rate - and Pd's message rate or signal rate - but i don't understand it.
- do you need to declare you digital ins? what exactly is necessary?
alt text
alt text
- how do you boost the line in signal of the line in - by multiplying it?
[adc~]
|
[*~ 5]
- If I understand it correctly, if your patch has no subpatches, it should be called _main.pd and uploaded and compiled to Bela

Confused beginner's questions..

Thanks!

dywen

    Digital I/O at signal rate means that you read or write your audio signal using [adc~] and [dac~], just like for an audio signal, however this gets quantized to 0 or 1 before it is sent out.
    Digital I/O at message rate means that you receive a message every time the input value changes ( for inputs ), or that the output value changes evert time you send it a message (for outputs).

    The baudrate of an Arduino specifies the speed of the connection, and has no analogy with any of the above. In one of your notes you seem to interpret the [metro 200] as setting the baudrate. No, if anything, the analogy with Arduino would be, assuming that you do serial.print() once per loop(), and that loop() always takes the time to execute, then 200 would be the duration of loop(); conversely, it means that you would receive a message from Arduino every 200ms.

    In your case you probably want to set an input as signal rate. You mentioned digitalIn 3, 4, 5, which in Bela-Pd terms translates to 14, 15, 16. So first thing you need to initialize the channels as inputs at message rate:

    [loadbang] 
|
[in 14, in 15, in 16(
|
[s bela_setDigital]

    then you can receive from each of the following accordingly:

    [r bela_digitalIn14]
|
[print digitalIn14]

    this way you will see a message printed in the console (0 or 1) every time your button changes state. In your patch you can use

    [r bela_digitalIn14]
|
[sel 1]
|
[t b b (
|
...

    Regarding the @hv_param thing, that is needed only when using Pd with Heavy (see here), but you can probably ignore it for now.

    dywen - how do you boost the line in signal of the line in - by multiplying it?
    [adc~]
    |
    [*~ 5]

    yes: it's just an audio signal

    dywen - If I understand it correctly, if your patch has no subpatches, it should be called _main.pd and uploaded and compiled to Bela

    even if it has subpatches, or abstractions, there always has to be one file called _main.pd, which is the "main" file of your patch, that is the one that you would open on the host when starting the project.

        In Dutch we have an expression - as clear as water from the pump = crystal clear!

        Thanks, I needed that :-)
        I still have some mechanical questions (what happens with debounce for example) but I will tackle that when I hopefully find a little opening somewhere in between meetings/project etc tomorrow. Can't wait..

        Have a pleasant evening!
        dyWen

        5 days later

        Hi,
        Finally found some Bela time..

        • the three buttons are connected to digital 13, 14 and 15 of Bela on the one side
        • the other legs go to 3V - is this correct?
          (to ground did not do anything)

        I have adapted and changed the patch - debounce is definitely necessary.
        However it does not seem to work, the debounce, in my frankenpd.

        • Does it have anything to do with the proposed patch from github working with floats?
        • When I launch the code, the button on digital 2 immediately gives me a 1 in the console, without being pushed (I will now check that physical button)

        alt text
        alt text
        alt text

        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
          alt text

        • Button 14 pressed once
          alt text

        • Button 15 pressed once
          alt text

        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..

        alt text
        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.

          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

          • Pushing the play button only works when I press the button (I have to keep it pressed)
            Again, a Pure Data issue - I'm going to try and solve it with spigot

            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

                      22 days later

                      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 :-/
                      alt text
                      alt text

                      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