Hi!

I just started to learn Bela and PD a few days ago...

My primary goal is to build a standalone Midi-To-CV "device" and use it in my upcoming eurorack performances.
I`m planning to generate six ADSR envelopes, two MidiCC-to-CVs and eight Gate signals with the Bela and control everything via USB-Midi. I also need to use about 60-80 Midi CC channels to set everything properly.

So far everything worked fine. I did some simple experiments with PD running LEDs with Bela`s Analog/Digital Outputs, tested it with my eurorack system and also made my own custom phasor~-based ADSR in PD.

Now I did a simple test-patch with the six ADSRs to see how it runs on the Bela.
After I executed the patch the IDE disconneced... I think this was because the PD overloads the CPU.
The Bela looked running more or less, some LEDs was blinking.
Then I simplified the PD patches and switched to message-rate Digital Outputs but it doesn't solved my problem. The funny thing is if I remove that ONE connection that triggers the envelopes randomly and execute the patch, it don`t disconnects! In that situation the IDE shows ~50% CPU load.

Is it possible to somehow lower the sample-rate to save CPU? I`m not planning to use the Audio Outputs.

Or can You help me how to optimise my patches? I don't think they are too big. Maybe I did something very bad, I`m totally new to PD...
Here are the PD files:
https://drive.google.com/open?id=1EGuHhcf4dDizS_ZZIk77w2cg8y67pmCz

Thank you in advance!
Cheers
Adam

I guess that will depend on how often you trigger that envelope. Which is that ONE connection?

Hi giuliomoro !

Thank you very much for your reply!

Since then I tried a lot of things but nothing helped... I`m afraid there can be a bottleneck with midi inside libpd.
I made two PD files to demonstrate it:

https://drive.google.com/open?id=1RVUkDswRqMm36hlHOZtqq1x5F3pFINHb
This patch is for Bela. It runs four of my adsr envelopes and outputs them on Analog 1-4. Each envelope has nine parameters and they are controlled by midi cc messages, so there are 36 ctlin objects too.
The purpose of this patch is to generate Amplitude- Pitch and Filter Envelopes for my eurorack modules.

https://drive.google.com/open?id=1t2wmndr3N-tOGAtF0RNzuGYQloFcc0dv
This is a remote patch for the _main.pd . You can tweak all parameters with hsliders. It has also a random note generator and a parameter randomizer.

So, if I execute the main patch on Bela everything goes well, it uses ~63% of CPU.
I can trigger the Envelopes with the remote patch, everyhing is OK and works as expected!
Then when I start to send midi CC messages everything goes crazy...
- the CPU usage rises with each midi CC message
- the console starts saying: Underrun detected: 1 blocks dropped
- in the same time the singnals on Analog 1-4 starts to drop out
- by time it gets lot worse
- with four envelopes CPU goes up to 90%
- if I do the same with a five envelope patch the IDE disconnects.

It looks like midi CC channels are eating up the CPU and Bela goes glitchy... :-(

I tested it with a two envelope patch (Amplitude and Pitch), and it went very well! I used it with the Mutable Instuments Braids module and I was very happy with the results, it produced the best kick-drums I`ve ever heard! :-) So I think the idea is good!
But my goal is to run 6-7 envelopes, 1-2 CC-to-CVs and 8 gate outputs in the same time.
And it needs to deal with very-very dense midi input, because when I perform music I have about 400-800 midi events per second!

Now I dropped PD and started to learn C++.

What do you think? Is it possible to do it with PD or C++ ?
I think my needs are not too big, but what do you think? Can I make it with Bela?

Thank you in advance!
Cheers
Adam

    skogn the CPU usage rises with each midi CC message

    hmm this could be a bug. Do you mean that every time you send a message the CPU usage increases and never goes back to normal, even after you stop sending messages?

    skogn So, if I execute the main patch on Bela everything goes well, it uses ~63% of CPU.

    With how many envelopes? Is that the CPU usage before you send any messages?

    skogn And it needs to deal with very-very dense midi input, because when I perform music I have about 400-800 midi events per second!

    Now that's a lot of events. Do they all need to get into the Bela? Probably you will have to increase the block size. Have you tried that yet?

    skogn What do you think? Is it possible to do it with PD or C++ ?

    I am fairly sure Pd should be fine. I will have a look at your patches, but it may take a few days. Be patient if you can! In the meantime ...

    skogn Now I dropped PD and started to learn C++.

    ... that's always a good exercise 🙂 . In fact this patch seems like a very good starting point for learning C++.

    Quickly looking at your patch I have some observations:

    • if the CPU usage is high before sending any message, then most likely the culprit are the signal rate (~) objects.
    • [expr] and [expr~] tend to be very expensive. Sometimes replacing them with the equivalent discrete blocks will make it sensibly more efficient*.
    • My best guess is that the pow() inside your [expr~] are the CPU suckers just now.
    • if you get a dropout every time you send one message, then:
      • I think (but I am not entirely sure) that parsing strings (e.g.: what you are doing with [route]) is more expensive than routing floats, so you could try to replace those strings with floats?
      • I think (but I am not entirely sure) that [t b b b b] is significantly more expensive than the equivalent 
        [bang]
|
[t a a a a ]
    • Overall, this looks exactly like the sort of Pd patch (i.e.: with many messages passed around) that the Heavy compiler (https://forum.bela.io/d/636-heavy-pd-and-enzienaudio/12) would be great at optimizing, so maybe (once you have replaced all the [expr] objects with discrete blocks (as [expr] and [expr~] are not supported by Heavy).

    * a quick trick to make patches simpler when "discretizing" [expr] is to remember that, e.g.: [expr 1/$f1] can be written either as:

    [t b f]
|    |
[1(  |
\   /
 [/ ]

    or, more simply:

    [1 $1(
|
[/ ]

                giuliomoro Do you mean that every time you send a message the CPU usage increases and never goes back to normal, even after you stop sending messages?

                The CPU usage increases only when I send a CC value to a "new" CC channel... and never goes back to normal.
                Looks like it`s with the Number of CC Channels, not the number of midi events.

                giuliomoro With how many envelopes? Is that the CPU usage before you send any messages?

                Four. The same patch as I attached.
                Yes, right after I executed the patch.

                giuliomoro Now that's a lot of events. Do they all need to get into the Bela?

                Actually, it`s a Max/MSP based MIDI sequencer running a complete eurorack system.
                I need Bela to help me out with clever ADSR envelopes :-)
                I can make a midi chain dedicated to the Bela if that helps.

                giuliomoro Probably you will have to increase the block size. Have you tried that yet?

                I tried, dont helped. Tried to use the -C 64 argument too.

                giuliomoro ... that's always a good exercise 🙂 . In fact this patch seems like a very good starting point for learning C++.

                Yes, I hope so! :-) So far I`m going well with it.

                giuliomoro [expr] and [expr~] tend to be very expensive. Sometimes replacing them with the equivalent discrete blocks will make it sensibly more efficient*.
                My best guess is that the pow() inside your [expr~] are the CPU suckers just now.

                Hmmm... I didn`t know that.

                giuliomoro I think (but I am not entirely sure) that parsing strings (e.g.: what you are doing with [route]) is more expensive than routing floats, so you could try to replace those strings with floats?
                I think (but I am not entirely sure) that [t b b b b] is significantly more expensive than the equivalent

                Thanks for ALL of your advises!
                I will rebuild the patch with this guide and get back soon.

                Cheers

                                skogn My best guess is that the pow() inside your [expr~] are the CPU suckers just now.

                                If "discretizing" the [expr~] does not help, I could try to compile libpd using a fast implementation for pow instead of the stock one.

                                skogn The CPU usage increases only when I send a CC value to a "new" CC channel... and never goes back to normal.

                                Ok that is weird to me, I cannot see just now where the problem could lie. This requires some more investigation.

                                    Many Thanks for Your advises but finally I ended up using PD because I was worried about how far I can go with it.... but I recreated the same functionality in C++ successfully!
                                    Now it runs seven ADSR envelopes and accepts full MIDI control.
                                    I tested it with the eurorack and I am very happy with the result!
                                    It uses only 27% of CPU, so I can add the rest of the functions, like gate outputs, control smoothing, etc...
                                    Here is the code, but it`s very quick&dirty... my first try :-)
                                    https://drive.google.com/open?id=1Tl5LQzXmxM2JZ8gYN995piOhV50sg--4
                                    Cheers