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.

                    cmm Important to note that you need to include the cyclone/ part of the object name..I wouldn't have thought of that.

                    yes I mentioned it up here

                    giuliomoro (e.g.: [cyclone/delay~]),

                    This is due to the folder structure of the Cyclone externals: all the externals live as file in the cyclone/ folder. If you want, you can add another line

                    	libpd_add_to_search_path("../pd-externals/cyclone");

                    to the core/default_libpd_render.cpp file, https://github.com/BelaPlatform/Bela/blob/master/core/default_libpd_render.cpp#L382-L383, if you want the setting to be applied to all your projects, or provide a custom render.cpp file with this change if you want it to be applied only to a specific project.

                    • cmm replied to this.

                          giuliomoro yeah, I would have been lost if you hadn't said that, I was going in circles until I remembered your post. It's not something I've ever needed to do in Pd before.

                            You have to do it also in Pd unless you set up the path in the preferences.

                            12 days later

                            giuliomoro Hi, could you exactly explain how to do that? it doesn't seem to work for me...i have a patch .pd with a external library object; which file should i place inside projects/pd-externals? the .c or the .pd_linux? At the moment neither is working for me...

                              It's always the .pd_linux that needs to go in projects/pd-externals. If you have a library external, then you have to create an object with the name of the library FIRST, then you can create all the objects from the library. For instance:

                              [zexy]

                              then

                              [pack~]

                              CAVEAT: the main library object ([zexy]) needs to be created BEFORE you try to create the individual objects. The order in which objects are created is the order in which they are in the plain-text representation of the Pd patch. Basically, there is no way of telling just by looking at the patch, and you cannot arbitrarily move them around in the text file. So the solution is: cut everything except the main library object, then paste everything: the newly pasted objects will be created by Pd after whatever was there.

                              Alternatively, the proper way of doing it should be: [declare -lib zexy], but I have not tested this on Bela.