thetechnobear I would like some kind of CV connections as well as your suggestions especially the rotary encoders. That is why I am hanging on hoping for the Bela CV module. This is all good I still have a way to go understanding PD patches in Bela but that is my issue. Good luck on making yours...

    7 months later

    Hi,

    I've been trying to compile an external to use with the Bela. The instructions I've been able to parse from above don't seem to work, first of all because there doesn't seem to a libpd file in the include directory:

    alt text

    Is there a new process for this? I haven't been able to find anything else recent in the forum about making externals on the board.

    Thanks,
    Colin

    Yeah sorry the include folder is now in /usr/local/include/libpd

    I updated the posts above to reflect this.

      so if you are cross-compiling, you will need to copy those files from the board on to your computer (or mount the filesystem remotely)

      I'm trying to build the external on the Bela, so no cross compiling. Just looking for a proper Makefile now.

      5 days later

      giuliomoro
      I have an external that seems to have compiled ok, but doesn't seem to be functioning properly on the Bela. It works fine on all other systems - I've tested it on OSX, Windows 10, and Ubuntu. For some reason, I can't get proper values when I run it on the Bela. I'm wondering if I could send you the files and have you double check them. I totally understand if this is a pain, though. In case it's not and you have a spare moment... The object does a cross correlation on two audio signals and writes the result to an array (first outlet), as well as provides the index from the center of the array (second outlet), and gives the peak value (third outlet). The first two inlets are for the audio signal, and the third is for a calibration input (which doesn't seem to be working, hence the expr~ object). Here is a link to all the necessary files to compile and run if you do have the inclination: https://www.dropbox.com/s/g5wtmicokn1r1xg/xcorr.zip?dl=0

      Thanks!
      Colin

        Hi Colin,
        the difference between platforms could be due to the fact that on Bela Pd's internal blocksize is 16, while in Pd it defaults to 64. Your code does an FFT of the size of the incoming buffer, so maybe mayer_reallfft() does not like an FFT of size 16?

        Note that you cannot change this parameter at runtime: you would need to recompile libpd editing

        #define DEFDACBLKSIZE 16

        to

        #define DEFDACBLKSIZE 64

        in

        libpd/pure-data/src/s_stuff.h

        To recompile libpd:

        git clone https://github.com/BelaPlatform/libpd.git
git submodule init
git submodule update --recursive
.... do your change to pure-data/src/s_stuff.h
make -f Makefile-Bela
make -f Makefile-Bela install

        PS: I like the comments to the Pd API in your xcorr~.cfile: very instructive.

        EDIT: using https for git clone

        I was thinking it could be a block size issue and changed the block size in the project settings, but I'll go ahead and recompile libPd. I'll let you know if that works.

        Thanks as always!

        Hi Giulio,

        I tried cloning the repository, but got:
        '''
        root@bela:~# git clone git@github.com:BelaPlatform/libpd.git
        Cloning into 'libpd'...
        Permission denied (publickey).
        fatal: Could not read from remote repository.

        Please make sure you have the correct access rights
        and the repository exists.
        '''
        Is that the right address, or do I need access or something?

        it means you don't have an ssh key stored on github, or if you do, you don't have enabled key forwarding to your Bela. You can clone via https:

        git clone https://github.com/BelaPlatform/libpd.git

          giuliomoro
          When I try to update the submodule, I get:

          root@bela:~/Robut/libpd# git submodule update --recursive
Fetched in submodule path 'pure-data', but it did not contain 5d1f09c51390f073f671121842b402f55531eebf. Direct fetching of that commit failed.

          and then there's nothing in the pure-data folder - no src/s_stuff.h file.

            oh I see: the pure-data repo was still pointing at Miller's one. I updated the libpd repo now to point to my pure-data fork, try again.

            Awesome! That seems to have done it! I'm getting predictable values from the [xcorr~] object now.

            Thank you!!!

            Great. There were talks at some point in the Pd mailing list about making that #define a run-time variable, but nothing came out of it I think.

            4 months later

            I'm working on a project where some existing externals would come in really handy. I have to confess that I'm struggling a bit trying to work out a method to compile and install based on the above discussion, has anyone got a set of instructions that I could try to follow?

            Also seems worth asking: has anyone had any luck with the cyclone objects? I noticed mention of a compatibility issue on another thread https://forum.bela.io/d/374-reading-jpeg-or-video-from-sd-card-to-bela-as-arrays

              cmm Also seems worth asking: has anyone had any luck with the cyclone objects?

              now we are on Pd 0.48, so cyclone should work now. Also, something else has changed from the earlier part of this thread: the m_pd.h file needed by the externals now lives in /usr/local/include/libpd.

              cmm to confess that I'm struggling a bit trying to work out a method to compile and install based on the above discussion, has anyone got a set of instructions that I could try to follow?

              It really depends on the build method used by the externals that you want to compile. In the case of cyclone, it seems that it is using pd-lib-builder. Looking at the built-in readme it seems that you can simply do:

              make PDINCLUDEDIR=/usr/local/include/libpd PDLIBDIR=/root/Bela/projects/pd-externals install

              The PDLIBDIR points to the path where the built externals will be copied (this is one of the paths were our Pd wrapper checks for externals).

              However, the above fails, because cyclone needs some more header files than the ones we ship with libpd (maybe I should just include them all?). So you will have to grab a copy of our Pd fork here and put it on the board, e.g.: in /root/pure-data. At that point, change the line above to

              make PDINCLUDEDIR=/root/pure-data/src/ PDLIBDIR=/root/Bela/projects/pd-externals install

              also make sure your Bela code is updated to the latest version (which will guarantee the header files you get from our pure-data fork will match the version of libpd you have installed)!

              Doing the above successfully builds and install cyclone (it takes about 10min). Then I verified that I can create a cyclone object in a Pd patch (e.g.: [cyclone/delay~]), so it seems to work, but I have not tested functionalities.

                    hey guys,
                    just my two cents here.
                    I m working on a project with Bela and successfully using PD externals compiled with a Raspberry Pi3.
                    I started from the assumption that if the external was compiled on ARM, then it might work on another ARM based Linux platform and indeed most of them did work (including cyclone).
                    @giuliomoro : any possible negative consequences by doing this?
                    Thank you
                    L

                    It really depends on the Pd external in question and its dependencies. Only the file m_pd.h is guaranteed to never change for Pd (or to change in a backwards compatible way). This means that as long as the external was built for an older version of Pd than the one you have and it was only using m_pd.h, then you are most likely fine, assuming:
                    - same architecture
                    - that you have on your system any shared libraries that your external depends on
                    - that the shared libraries you have are compatible (e.g.: your version is the same or is backwards compatible)
                    however, if the externals use some more of Pd's .h files, then in order to have guaranteed working externals, they'd have to be built specifically for the version of Pd you are running on. This means same version, but also same fork. In the case of our fork, the changes are minimal, and you'd probably be fine with something built for the same version of Pd.
                    cyclone does use some Pd's internal .h, so I'd recommend you build it on the board, however you are free to try with the pre-built binaries and check if practically it works ok or not.

                    Ok clear, thanks a lot for the explanation.
                    I actually compiled with success also libraries with other dependencies (like the brilliant TimbreID by William Brent), always on a RPi3, then copied the binaries in my Bela project folder. But yeah, will definitely try to compile something directly on the Bela next time.
                    Anyway, for what it matters, I haven't experienced any problems so far with debian pre-built cyclone (although I have used a fraction of the available objects).
                    My biggest worry was more if that could lead to crashes or any sort of instability?

                    giuliomoro Thanks. That worked, patching on Bela is going to be so much smoother with these as a former Max-head! Important to note that you need to include the cyclone/ part of the object name..I wouldn't have thought of that.