Hi,
I'm trying to read OSC data in PD (running on my laptop) from analog sensors. I'm using a very simple code :

#include <Bela.h>
#include <OSCClient.h>
OSCClient oscClient;
int parseMessage(oscpkt::Message msg);
int remotePort = 9000;
const char* remoteIp = "192.168.7.1";
bool setup(BelaContext *context, void *userData)
{
    oscClient.setup(remotePort, remoteIp);
	return true;
}
void render(BelaContext *context, void *userData)
{
    oscClient.queueMessage(oscClient.newMessage.to("/adxl-x").add(analogRead(context,0,0)).end());
}
void cleanup(BelaContext *context, void *userData)
{
}

The data is kinda received in PD, but it is delayed (by about one second), and the GUI in PD totally crashes. PD gets back to normal when I stop the program on bela. I have the same problem using [udpreceive] and [netreceive]. I know the problem doesn't come from my PD patch, as it happens with only one object (udpreceive and netreceive). Is there something wrong with my code? I have "mode switches detected on the audio thread!" error messages, could it be related?

I just figured something out : the bug is triggered when I select my sound card in the PD preferences. If I launch PD with default audio settings (built-in sound card) everything works fine. Isn't it strange? I use PD 0.48-1, RME fireface uc (usb).

That does not seem to be a problem with Bela. The C++ code you have sends an OSC message every block, which defaults to 16 samples, that is 16/44100 = 362us, that is about 3000 messages per second. The program running on your host (Pd) has therefore to cope with a large-ish stream of data and it seems to be lagging behind (hence the 1 second delay) and probably it is just hiccupping and dropping packets at some point. I am not sure why changing the audio interface in use would make a difference here. Most likely it has to do with the actual audio buffer size used by the card (which is related to the "delay" parameter in Pd, not only the "blocksize" value). What is your "Delay (msec)" value in Pd? I suggest you post this issue to the PureData repo, mentioning you are receiving a stream of 3000 OSC messages per second.

Thanks for your answer. From what I've read I can't set the buffer size with my soundcard on osx. Changing the block size or the delay (my default is 5 ms) doesn't help. I've even tried to put [upreceive] in a subwindow with [block~ 2048], doesn't work either. The only thing that works is to set bela's block size to 128. I find it weird, it seems to work perfectly at 128, and there is no difference between 16 and 64. Also, the cpu load remains very low, between 5 and 7, and doesn't go up when things go wrong...

Considering all this, would you say i'm safe using 128 samples block size? I'm planning to use bela for a concert next week, so I need something very reliable. If not, i guess i'll switch to MIDI, hoping i won't go through similar issues... Is MIDI through usb supposed to be easy to set up? I've had a look at the render.cpp midi example, right now it's mumbo jumbo to me, and I've spent the entire day working on this OSC thing, i'm quite reluctant to give up on it...

    LucienR The only thing that works is to set bela's block size to 128.

    The code on Bela as you wrote it sends out one OSC message per block, so with a block size of 128 that is about 344 messages per second, which seems to be a value that your host can handle. You can rewrite the code so that it sends messages at a given interval, independent of the block size if you wish.

    LucienR doesn't go up when things go wrong...

    what do you mean when things go wrong? Is this the CPU load on Bela or on the host? If this refers to the mode switches on Bela, then yes it's normal that Bela's CPU usage does not increase when they happen. The audio on Bela may have a glitch at that point, but it seems that you are not using it?

    MIDI over USB works if you have a Bela image v0.3 or above (you do if you got the board after November 2017). You should see the Bela showing up as a MIDI device on the host. Go to Audio MIDI setup and you should see the device there as "USB Midi" device. You can rename it if that is convenient to you. Anyhow, you will then be able to open it from Pd.

    alt text

    If you put this bit of code in your Pd patch, it should take care of opening the interface hw:0,0,0 on Bela, which is the one that shows up on your host, so you can then use [noteout] or [ctlout] to send messages to the host.
    Fully working example (run this on Bela):

    alt text

          giuliomoro what do you mean when things go wrong? Is this the CPU load on Bela or on the host?

          I mean PD on the host keeps a very low cpu load even when it seems completely overwhelmed.

          giuliomoro You can rewrite the code so that it sends messages at a given interval, independent of the block size if you wish.

          I thought of that, but i'm a total noob with c++, i have no idea how to do it, i tried to use sleep() but i can't use it properly.

          Anyway, I guess I'm going to use MIDI, it seems safer at this point. Thanks for the example, it actually looks quite easy to use.

          EDIT - With midi I have the IDE's terminal displaying every MIDI message, can I turn that off?

          EDIT 2 - It works fine with libpd, but not with heavy, is it normal? I compile and run it without error messages, but I don't get any MIDI signal on my computer.

                LucienR It works fine with libpd, but not with heavy, is it normal? I compile and run it without error messages, but I don't get any MIDI signal on my computer.

                Yes I think it is expected. This is not implemented yet on heavy.

                    LucienR I thought of that, but i'm a total noob with c++, i have no idea how to do it, i tried to use sleep() but i can't use it properly.

                    You are not meant to use sleep() inside the render() callback: that function is called at regular intervals depending on the block size and it needs to be done completely before the next time it is called. sleep() would make it overrun.

                    For the records, this would have worked to send messages at a given rate:

                    int gIntervalSamples = 441; // send every 441 samples, that is 100 times per second
void render(BelaContext *context, void *userData)
{
    static int count = 0;
    for(int n = 0; n < context->audioFrames; ++n)
    {
        if(count == gIntervalSamples)
        {
            count = 0;
            oscClient.queueMessage(oscClient.newMessage.to("/adxl-x").add(analogRead(context,0,0)).end());
        }
        ++count;
    }
}

                        giuliomoro Yes I think it is expected. This is not implemented yet on heavy.

                        @LucienR if you are using heavy, you can set it to use the hw:0,0,0 by editing the file in scripts/hvresources/render.cpp on the host computer: search for the two occurrencies of hw:1,0,0 in the file and replace it with hw:0,0,0.

                          Ok thanks a lot Giulio. I think I'll stick to MIDI for my current project, and try again later with OSC.