String class performance

#1

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.

thanks.

#2

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 ?

#3

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.

#4

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]

#5

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.

#6