What's new

Custom Playback Rules in Staffpad - The mini "crashed" course.

Yesterday, I was speachless, when I saw that the tutorial was shut down. The gentle breeze of fresh air, which Servandus createt with his tutorial was so refreshing. His suggestions and the whole Tutorial were brilliant. Real Teaching in 21st Century. Everything so clearly put down. But the Window to this was shut yesterday by the Developers. Madness!!!

It is a good Idea to concentrate the Efforts now on Dorico 4. But as I understand the Playback Architecture of both apps, Dorico can not manage the Legato transitions, we are used to have in Staffpad, because of real time Playback.

And what I dont understand is the whole Situation. What would happen to us, if we continue to discuss some steps to tweak an xml File, e.g. to even out the Staccato-Legato Dynamic Differences in this Forum. Perhaps not in the perfect Form like Servandus offered in his Thread. Is this illegal?
 
@servandus I wish you would repost the playback example that you sent to StaffPad so that people who look at this in the future can see what they rejected. I want to look back at it myself once in a while to remind myself what was lost.
 
That's right, that video in itself can't be a problem and it was a magnificent documentation of everything that's been going on...
 
It is available cached on google along with a fair amount of the thread
I finally found the cached thread on Google. (Not a Google user, so it took a bit.) Unfortunately, Page 6 where Sevandus reported his submission and included his video was not yet indexed before the page came down.
 
Ah sorry I thought it had got that page
There's another good example there on Page ?-- I forget. Even if I had the whole thread intact and the skills to exploit it, it is far more complicated on iOS, so I wouldn't bother with it. I am moving on, building Dorico templates. The indifference, the apathy, and the callousness shown to Servandus by DWH are unforgivable to me. Once we saw how great this thing could sound with minimal effort, it became apparent to me that there was no future here. To think all this time that all that potential was just lying there fallow. . .it boggles the mind. It couldn't be chalked up to anything other than sheer laziness and total disregard for the user base. (Much like the missing articulation lists.) I had been strongly recommending it to all of my students and colleagues, but no more. I will continue to use it as a sketchpad because I am heavily invested in it (23 libraries), but I will actively ward people away from it now. Perhaps some day I can discourage as many people from it as I have encouraged to it.
 
I mean, I never had any high expectations for customizability on an iOS app to begin with. My biggest concern is still the handwriting detection, which I would happy contribute my handwriting to in order to help their detection engine.
 
There's another good example there on Page ?-- I forget. Even if I had the whole thread intact and the skills to exploit it, it is far more complicated on iOS, so I wouldn't bother with it. I am moving on, building Dorico templates. The indifference, the apathy, and the callousness shown to Servandus by DWH are unforgivable to me. Once we saw how great this thing could sound with minimal effort, it became apparent to me that there was no future here. To think all this time that all that potential was just lying there fallow. . .it boggles the mind. It couldn't be chalked up to anything other than sheer laziness and total disregard for the user base. (Much like the missing articulation lists.) I had been strongly recommending it to all of my students and colleagues, but no more. I will continue to use it as a sketchpad because I am heavily invested in it (23 libraries), but I will actively ward people away from it now. Perhaps some day I can discourage as many people from it as I have encouraged to it.
You express many things I felt since I read the excerpts of DWH's reply to @servandus. Especially the fact that I always thought tweaking sample playback is a big endeavour, it takes patience...wow. That one gets more and more bitter by the hour.

As concerns the info buried in the deleted thread apart from the video demos: I really think it is not a good idea to follow those tips, now. We basically know now that the playback engine is eventually bound to break any tweaks you might add.
 
I mean, I never had any high expectations for customizability on an iOS app to begin with. My biggest concern is still the handwriting detection, which I would happy contribute my handwriting to in order to help their detection engine.
I agree and I never expected customization on iOS - the big big big problem I have is servandus showed us that playback/library/whatever bugs and inconsistencies we've been complaining about and reporting to StaffPad have fixes that are but a few XML tweaks away - yet StaffPad/MuseScore refuses to fix anything. Not to mention the hidden great-sounding articulations that were discovered and are unavailable to us.

For me, and this is just my opinion, I can live with the terrible handwriting recognition (which I'm not disagreeing about), but for a product whose claim to fame is it's playback engine and library integration - it's unforgivable that the associated issues receive zero priority. Coupled with DWH's take on the matter, hard for me to stomach.

If anything drives me away that will be it. At the moment I'm not very eager to invest in and learn another tool (Dorico, expression maps, etc.)...

Rock, meet hard place...

Edit to add: it's really difficult now for me to pick up StaffPad and get anything done, now that I know the things I wrestle with could and should be fixed so easily...
 
I think DWH is trying to keep in the good graces of Apple. StaffPad was featured at an Apple event last year - how many apps get featured like that? We all know Apple goes berserk over any kind of customization on iOS apps that they feel could even possibly lead to a security risk. They infamously refuse to allow apps that let you run unsigned software of any kind. Maybe DWH is trying not to upset Apple by issuing a reply which echoes the EULA, and maybe the original thread’s deletion was a complete over-reaction.
 
I agree and I never expected customization on iOS - the big big big problem I have is servandus showed us that playback/library/whatever bugs and inconsistencies we've been complaining about and reporting to StaffPad have fixes that are but a few XML tweaks away - yet StaffPad/MuseScore refuses to fix anything. Not to mention the hidden great-sounding articulations that were discovered and are unavailable to us.

For me, and this is just my opinion, I can live with the terrible handwriting recognition (which I'm not disagreeing about), but for a product whose claim to fame is it's playback engine and library integration - it's unforgivable that the associated issues receive zero priority. Coupled with DWH's take on the matter, hard for me to stomach.

If anything drives me away that will be it. At the moment I'm not very eager to invest in and learn another tool (Dorico, expression maps, etc.)...

Rock, meet hard place...

Edit to add: it's really difficult now for me to pick up StaffPad and get anything done, now that I know the things I wrestle with could and should be fixed so easily...
On top of that I don't understand why editing these xml files is against the law
 
Reverse engineering is legally complex as is anything when the legalities have to be taken into account. On top of everything else, the situation differs from country to country.
Considering the EULA, in Germany, e.g. you are not legally bound to the contents of any EULA that was presented to you only after buying. Also, if you read up on reverse engineering and legalities on Wikipedia you notice the sections say very different things in English and in German, i.e. the boundary between the rights of creators and users runs along very separate paths wether you are in the U.S or in Europe.

You could also argue that calling what servandus did a breach of EULA by reverse engineering is a load of bullocks, because he did not even reverse engineer the software itself, but just figured out the rules of some open protocols (in order to repair a malfunctioning software to boot).

But all that is irrelevant, actually. At least in my opinion. Relevant is:
- Staffpad does not care for user input
- They want that whole community driven help and effort shut down
- They will not mind any community modifications in further updates on the playback engine which might render every effort useless in the long run

It's a cultural mismatch. We thought we were users and might become a community. They just want consumers.
 
For me personally I really like Staffpad.

I happily paid a lot of money for the add-on libraries. I really really like the playback engine that sounds (to my ears) good and runs on a handheld computer the thickness of a piece of glass (can't tell you how tired I am of rinky dinky midi playback engines that sound like they came from a cheap game console from 1991).

I enjoy avoiding the hugh number of tracks I need to put into a Cubase or Logic template to deal with all possible articulations and enjoy simply writing music that I can see what is doing just by looking at the notes, symbols, etc (really don't like the mess that comes with composing with piano rolls, midi cc's, hugh templates and instrument sets).

I respect that the Staffpad developers have a vision and want to stick to it, vision is a good thing.

What I'm struggling with is why the developers of Staffpad feel it is necessary to shut down productive input from a very creative user community.

Look at Apple, they barely make any software. They let their customer base do all of the work and take in the lions share of the profits. Keeping a stranglehold on having the user community extend and enhance Staffpad is foolish and shortsighted.
 
Hello,
First, @servandus thank you very much for your work on StaffPad articulations, and so sorry it ended like this, although, as a (iOS) developer, I can understand some part of the answer you received.
Making public some private things means big work: add an UI for the customization, take in account all the user can do and try not to mess with the playback or even worse make the app crashing, even if you demonstrate that articulation customization can be done, add application testing, beta testers, ...

Then, as a StaffPad user (on iPad), using Berlin libraries, what I miss like many others is articulations consistency in existence and in volume. I said in your previous deleted post that I wanted to post something about strange articulations behavior but was waiting for the StaffPad answer.

I'm afraid the only thing we can post to be able to help with these articulation problems is, apart from reporting them to the StaffPad support (and we should do IMO), try to find solutions with what we have in hands.

I began to test just the marcato articulation with the Berlin library and will share my results in a new thread in a few days, trying to provide solutions to problems, like a beginning of a database or a spreadsheet for a reference.

Regards,
Gil.
 
Top Bottom