ireal b web editor discontinued

[bztk]

The original iReal HTTP string was pretty straight forward text but they did away with it around the time they went to iReal Pro. I think they consciously closed the door to file generation and importation from other sources

[pdxdjazz]

I suspect that in order to include information about player settings, transposition etc. that would transfer between devices, the song coding needed to be updated.

Originally, when you emailed a chart or playlist, all the settings for each song would reset to default values. Each chart in the transferred playlist would have to be inspected and checked (and readjusted if necessary) before the gig.... After many requests, the code was updated to ensure the retention of important performance data.

Also, there used to be more discussion relating to songs not transferring due to their files becoming corrupted during the email process. iReal PRO doesn't seem to experience that problem.

As features are added, everything (song code, user interface etc.) becomes more complex.

)BOB

[bztk]

I might buy that if they had kept the string sequential instead of breaking it into odd size pieces and shuffling them around, inverting packets etc.

I think they went small and close to the vest instead of big and open. If it were more accessible people would be building editors, links to other data, more styles etc. Then more folks from other types of music would be drawn to it. But it would be a bigger management headache

There were some iReal editors before the changes and folks have offered to develop more styles. Philosophically I think the developers are Jazz guys, teachers and students and that's their target audience. Their interest is in their music and not marketing iRealPro and growing the user base. A decision lots of musicians would probably make.

[sciurius]

I think iRealPro introduced the irealb:// data obfuscation mainly to discourage users from manually crafting and changing data as this may easily lead to import and other problems. For example, with the plain text irealbook:// data, nothing will stop you from changing a time signature into something invalid, e.g. 8/4. Upon import iRealPro will crash in a horrible way. You can argue that the app should do better checking on what it is importing, but that's easier said than done. With obfuscation added there's a strong signal that you are dealing with data that should not be tampered with.

Unless you know what you are doing, of course . Over the years I have developed some tools that I use to convert music data from other sources into irealbook:// data. It works nice, for me, and I haven't felt the need to switch to irealb://, especially since iRealPro has promised to not remove irealbook:// data import.

But actually there is not much mystery to the irealb:// data format. It is trivially obfuscated and slightly more complex (powerful) than the old format.