String class performance


I’ve made some code that parses strings (d0h). Anyways the parsing is done very often (on each knob move and there can be a lot of them, dynamic amount of knobs acutally). Thos knobs send MIDI messages that can be any king of MIDI messages, sa a XML is provided with a string describing the message like “:CC:120:1” wicth means MIDI type CC, number 120, channel 1, or F0:41:15:01:XX:0F - witch means SysEx with the XX as value from the knob. Now i parse theese using String class from Juce each time a knob is moved, using mostly substring() method.

Now will this be a cpu intensive task in temr sof 40-60 knobs moving (that’s what i predict will be a max amount). Or should i perhaps use some more low-level STRING functions i used to use like strtok() and strstr(). THough i was trying to keep the code clean from calls like that. Or am I safe with the String class and am not even near any performance issues with data liket that?. I’m asking cuase i don’t really have a testing environment for now and since the code is in it’s early stages it would be nice to implement theese core functions the right way for future use.



why you don’t simply precalculate those string and fill a struct when instantiating a knob, and then forget string parsing ? are those strings supposed to change over time ? why don’t you recalculate when they change only ?


i can do that and i’m thinking about it (i had some issues with that and tha’ts why i went the simpler rode). But i already have this code and it works so if it’s not a problem i’d like to leave it. That’s why i’m asking.


personally i would not use strings for such things! what are your strings for? are they for storing/recalling the type of data the knob will send? I made an app that had a customisable MIDI panel, and i wouldn’t have dreamt of parsing a string for the message with every adjustment.

If it is just for storing the type of message, just process the String from the XML file into a special data type [with flags for e.g. CC, SysEx, etc and members to hold the values it will use] and just use that information directly. Then of course process that information to turn it back into a String when writing it back to XML [or more simply, just use XML attributes to describe the knobs’ behaviour as i did - e.g. type=“cc” number=“1” pIndex=“2” (i.e. parameter index, the position in the SysEx string used as a parameter) etc]


the data is stored in a XML file so i have to take it as a string (actually as a char variable cause i want to stroe the vars later as structures and i can’t have classes ins tructures).

Like i said this seemed like the simplest and safest way ot of a problem, but i’m 90% of a time wrong. I’ll try to store the data in some better way then.

as it looks i have only bad ideas, i’ll ask some more:

a XML holds a definition for a modifier, the data property holds the MIDI message witch can be a predefined one begins with “:” ex. “:CC:120:2”, “:NRPN:264:4” etc. Or can be RAW data ex. “F0:0F:41:13:XX:0F” the RAW data can also be shot like: “0B:09:12”. There is also a override midi channel option for every panel of konbs that sends all messages on a perticular channel overriding the XML data property.

I should parse the data once, but the static not changable bits into a int array and just change the value of the knob when sending a message ?

Also i hold all the panel definitions (don’t kill me for this) in simple structures like

struct _knob
     int x,y,value;
     char name;

struct _slider
     int x,y,value;
     char name;
struct _panel
    struct _knob knobs[512];
    struct _slider sliders[512];
    int hardwareid;

why ? cauase i though (i didn’t do it yet), that insetad of serializing this to a XML again, i just pass the the whole structire array (like struct _panel panles[512]) to a blob of memory and than read it. A simple cast will put all the information in place without any re-parsing when the plug loads and closes. Is this a good way ? i’m thinking simplicity but like i said my ideas are mostly bad ones :).

any help much welcomed.