right I think you are missing a ";" between the "AT=" and "LD_FLAGS="
you need to put something like
AT=;LD_FLAGS=-lola;
see here

Right, sorry this is my fault all the way through. It should be "LDLIBS=-lola" and not LDFLAGS.
This is because the libraries (e..g.: -lola) should always come last in the command line.
Apologies.
NOTE: I edited the posts above to have LDLIBS instead of LDFLAGS to avoid confusion for newcomers.

make help would have helped:

Usage: make [target] CL=[command line options] [PROJECT=[projectName] | EXAMPLE=[exampleName]]

PROJECT or EXAMPLE should be set for all targets except: help coreclean distclean stop nostartup connect idestart idestop idestartup idenostartup ideconnect scsynthstart scsynthstop scsynthconnect scsynthstartup scsynthnostartup update checkupdate updateunsafe

Targets: (default: Bela)
list: Makefile
 This Makefile is intended for use on the BeagleBone Black itself
 and not for cross-compiling
 available command line options:
 EXAMPLE=          name of the folder in examples/ to be copied to projects/ and built
 PROJECT=          name of the folder in projects/ to be built
 CL=               list of command line options to pass to the program when running
 CPPFLAGS=         list of additional flags passed to the C++ compiler
 CFLAGS=           list of additional flags passed to the C compiler
 COMPILER=         compiler to use (clang or gcc)
 LDFLAGS=          linker flags (e.g.: -L. )
 LDLIBS=           libs to link in (e.g.: -lm )
 AT=              used instead of @ to silence the output. Defaults AT=@, use AT= for a very verbose output

available targets:
help:               Show this help
Bela:               Builds the Bela program with all the optimizations
all:                Same as Bela
debug:              Same as Bela but with debug flags and no optimizations
syntax:             Only checks syntax
projectclean:       Remove the PROJECT's build objects & binary
clean:              Same as projectclean
coreclean:          Remove the core's build objects
distclean:          Restores the Bela folder to a pristine state: remove all the projects source and the built objects, including the core Bela objects.
distcleannoprompt:  Same as distclean, but does not prompt for confirmation. Use with care.
run:                Run PROJECT in the foreground
runide:             Run PROJECT for IDE (foreground, no buffering)
runscreen:          Run PROJECT in the background (detached screen)
runscreenfg:        Run PROJECT in a screen in the foreground (can detach with ctrl-a ctrl-d)
nostartup:          No Bela project runs at startup
startuploop:        Makes PROJECT run at startup and restarts it if it crashes
startup:            Makes PROJECT run at startup
stop:               Stops any Bela program that is currently running
connect:            Connects to the running Bela program (if any), can detach with ctrl-a ctrl-d.
idestart:           Starts the on-board IDE
idestop:            Stops the on-board IDE
idestartup:         Enables the IDE at startup
idenostartup:       Disables the IDE at startup
ideconnect:         Brings in the foreground the IDE that currently is running in a screen (if any), can detach with ctrl-a ctrl-d.
scsynthstart:       Starts scsynth
scsynthstop:        Stops scsynth
scsynthconnect:     Brings in the foreground the scsynth that currently is running in a screen (if any), can detach with ctrl-a ctrl-d.
scsynthstartup:     Enables scsynth at startup
scsynthnostartup:   Disables scsynth at startup
updateclean:        Cleans the $(UPDATES_DIR) folder
checkupdate:        Unzips the zip file in $(UPDATES_DIR) and checks that it contains a valid
updateunsafe:       Installs the update from $(UPDATES_DIR) in a more brick-friendly way
update:             Installs the update from $(UPDATES_DIR)

Good to know about [make help]. Unfortunately still seems to have the issue:

alt text

Don't know if this helps, but this error only happens when I try and use an ola object or function. For example:

alt text
If I comment out the InitLogging line, it builds and runs without issue.

Right, so the [documentation for the library](
http://opendmx.net/index.php/OLA_Client_API) suggests to use:

-lola -lolacommon -lprotobuf

So try LDLIBS=-lola -lolacommon -lprotobuf;.

Even more interesting - because it applies to this whole set of problems - the appropriate way of getting the compiler/linker flags for any package installed with apt-get is something like:

$ pkg-config --cflags --libs libola
-I/usr/local/include  -L/usr/local/lib -lola -lolacommon -lprotobuf

Excellent! It's linking now. And thanks for the explanation! I'll be looking for those flags in the docs for future libraries.

Hey giuliomoro,
Thanks again for all the help. We've got another hopefully less complicated question, how do you run a command line command upon boot? Need to connect with this:

ola_patch -d 10 -p 0 -u 1

It's all working, but we want it to know to find and connect the proper device on its own.

I think when you set a project to run on boot from the IDE, it will run with the command line options that are currently active.

7 days later
giuliomoro changed the title to [Solved] Anyone try DMX controls yet?? .
giuliomoro changed the title to Anyone try DMX controls yet?? .
24 days later

Wait I guess I answered the wrong question, I assumed that ola_patch was the name of your Bela program. Instead, I understand now it is a different program altogether (the hint was -p 0, which does not make sense with Bela!).

You can add any command that you want to be executed at startup to the /root/Bela_startup.sh script, which is already executed at boot.
Note: this file is automatically re-generated by the IDE when you select a project to run on boot (which is the reason why in it you will find the line "Do not edit"). It is - however - safe to edit manually and rely on its content as long as you do not reset the "run on boot" program from the IDE.

Also, as a side note, I finally put together some instructions on how to use an external library, on the Blog.

3 years later

Dear @giuliomoro and @BitShapeSoft

I've been reading up on this thread and researching how to connect my Enttec USB Pro to my Bela, because I'm working on an audiovisual installation where I can't use laptops.

With a lot of help from a friend (Huge shoutout to Thom @ Notam), we have successfully installed OLA on my Bela. When i open the ola_dmxconsole, I can easily change the lights I have connected to the DMX USB Pro. So it definitely works!

But, I want to trigger the lights musically, be able to change colours and dimming in with sound etc., and the easiest fix would be a PD external that can pack control data from the PD environment and send it out the specified ports via the serial connection (USB Pro). We tried using Flext and downloaded the "ola2pd" external, but we get an error when it's trying to run in the web IDE. Have we overlooked something simple, or is there another way to do this? I have two Belas: is it an idea to do all audio/sensor-processing on Bela 1, send analog signals to Bela 2 and write a C++ application on Bela 2 that receives analog signals and sends DMX? Do you have some code / patches you could share, so I can see how you have done it?

I don't have too much time on this installation, so I would love some feedback on this - or if you have another, simpler solution for audio-controlled lights.

I think the simplest way to have this working with Pd on Bela would be to have a separate process receiving UDP messages from the Bela Pd patch. The reason why I say this is that many external and built in Pd objects behave in way that is not real-time safe, by doing I/O operations in the audio thread. This is definitely the case for comport, and I would expect it to be the case for ola2pd as well, though it's worth a try. On the Pd that runs on Bela I modified the netsend / netreceive objects so that they can be used safely, so they are a useful way to communicate with another process.
Another alternative would be to have a custom Bela wrapper for libpd which runs a separate thread where all the libola I/O is performed, and which receives messages from the main Pd thread. This workflow is explained in very generic terms here.

I can help with either of these.

Thanks for the fast reply, @giuliomoro !

Not sure what you mean specifically with separate processes, do you mean putting it all in the same PD-patch but putting a [netsend] after the signal processing, receive that signal with a [netreceive] in the same patch (as "safe guards"), before routing control data to the Enttec? Or sending the processed signal from PD with [udpsend], and then make a parallel C++ application/function that receives the data and routes it to the the Enttec? Or another solution?

Either of these solutions would be massively helpful, but I am unfortunately unable to program this myself. Any help, if you have time and want to help, would be incredible!

M

I meant an entirely separate program, yes. That could also be a Pd patch, with the two running in separate processes, and communicating over UDP. I'd say: see if you can compile the ola2pd object, and if that works and causes the message "mode switches detected in the audio thread", then we can look into running it in a separate process. Does that seem ok?