Hi,
is it possible to have a "_main.scd" patch in a Bela project and also use a "render.cpp" file, much like it can be done with PureData / C++ ?
Specifically, I'm curious to try to read from Trill Craft on Bela in a render.cpp file, and then just pass what I need to SuperCollider via OSC. The main patch however should run on SuperCollider!

Thanks for any hint,
best
Robin

    robinm is it possible to have a "_main.scd" patch in a Bela project and also use a "render.cpp" file, much like it can be done with PureData / C++ ?

    No that's not possible.

    robinm Specifically, I'm curious to try to read from Trill Craft on Bela in a render.cpp file, and then just pass what I need to SuperCollider via OSC. The main patch however should run on SuperCollider!

    Do you need to do any processing on the Trill readings before passing them onto Supercollider? This program acts as an OSC endpoint that receives messages to discover and set up trills and then can send OSC back with the readings. If it doesn't already do all you need, you can modify it with your custom C++ code so that it does. Once you have that working, you can run it as a service on your board alongside your Supercollider patch following the instructions here.

      giuliomoro No that's not possible.

      I see, is there any reason for this?

      giuliomoro This program acts as an OSC endpoint

      wow, cool! A little more to study before I can properly handle this but thanks for the hints 🙂 I was hoping to get to use jreus' TrillUGens actually, but I'm having some weird problems with those, I'll post in another thread

        robinm I see, is there any reason for this?

        In the case of PureData we are running libpd inside a C++ program that contains all the Bela I/O ("we added Pd support to a Bela project"). In the case of SuperCollider we added a Bela backend to scsynth ("we added Bela support to scsynth"). While there are ways of embedding libscsynth (Sc's equivalent to libpd) into any arbitrary C++ program, we haven't done that. So sure it can be done but it takes plenty of effort and almost always (like in this case) you'll find that the other solutions are much easier.

        robinm A little more to study before I can properly handle this but thanks for the hints

        Well if you are happy with what the program does (i.e.: work as a stand-alone Trill-OSC transceiver), then you don't need to write any C++ at all, just have it run alongside your Sc program. I don't have an example for that at the moment because I am really bad at Supercollider, but the enclosed PureData one should make it obvious.

        I appreciate jreus's effort to get the Trill ugens up and running, but I'd rather people use this approach instead as it is arguably easier to maintain. Anyhow, let me have a look at that issue.

          giuliomoro I will give you a proper feedback tomorrow when I'll try it, but nonetheless thanks a lot for the time you spend on this

            robinm I will give you a proper feedback tomorrow when I'll try it,

            well, or use the solution that I put on the other post to use the trill ugens

            giuliomoro I appreciate jreus's effort to get the Trill ugens up and running, but I'd rather people use this approach instead as it is arguably easier to maintain.

            Perhaps what's needed is to change the Sc class files for these ugens so that they keep the interface but connect to this stand-alone program instead of requiring the Trill ugens binaries ... This way they could be used from any Supercollider that has network access (or is on the same machine as) to an instance of the Trill-OSC program.

              giuliomoro
              It's not finding "udp.hh", do you know where to locate it to include it in the cpp sketch?

              giuliomoro
              sounds good, which of these ways (standalone, dedicated ugens, sc classes connecting to standalone) would be lighter / better performing?

                udp.hh is right there in the folder containing the cpp file.

                robinm which of these ways (standalone, dedicated ugens, sc classes connecting to standalone) would be lighter / better performing?

                Not sure. This approach requires osc parsing in scsynth, whereas the other one is built into scsynth so it doesn't have parsing overhead and has the potential to be lighter, but i wouldn't expect to see a significative penalty from this one especially when using a small number of trills. Need to investigate the causes of the ugen's cpu hog.