It really helps submitting problems as Bug following their template. If you have this problem and you have a few minutes to spare, I highly recommend it.
Iāll see if I can get around to it but hopefully somebody beats me to it. I only experienced this very recently and I think itās because I updated to 1.4.1 a day or two prior.
Just tested this on my play+ and it still occurs. When I had one full row of basic patterns with very few notes that was about 5 seconds save time. Then I added 4 additional rows with heavy variations usage and got to just short of 1 minute save time. Copy pasting time when doing this also increases a lot, but I only timed the saving time.
Bumping this as Iāve started to experience it as well.
I thought Iād found a perfect workflow for me. When developing a song idea, I work on a single huge pattern and make multiple variations of every track in it. Then if I want to build an actual arrangement, Iād just copy the pattern many many times, and on each copy, that represents a section of the song, Iād have different variations activated. Other variations stay intact, so I can easily switch them for every section afterwards if I decide to change something. Each track also has a dedicated empty variaton slot, to emulate track-solo-state-per-pattern.
This is where I stumbled across this issue. Every pattern copy iteration takes exponentially longer and longer time. Itās already about 15 sec for the ninth pattern. I remembered this thread existed, realized where things are going and so got frustrated. Have to give up on my āperfect workflowā because of this. Not sure how I should approach building the arrangement from now on. Copying tracks variations one-by-one from one pattern to another is so slow and annoying.
Is there a bug report for this yet? Should we make one if there isnāt?
There is no bug report on Backstage, but itās logged internally at Polyend as a bug
If youād like to have this tracked here, so you see any status updates (as they happen), feel free to create a Bug and iāll take care of it.
From an embedded software developer perspective - this is likely a bug. Even with a āslowā sd card, the patterns are tiny files (about 50k bytes) that should copy to the sd card almost instantly. Unless Polyend is using some really inefficient pattern db and doing tons of lookups on it, this simply shouldnāt happen. Itās also possible the Play is doing a batch of file I/O with the sd card, gathering info needed to create a new pattern. This would increase copy/write times as the project size increased. If thatās the case, then some serious optimizing is in order.
If Polyend is going to advertise 30,000 variations per project the developers and QA should have an āI/O torture testā project that stresses the file system just to make sure file I/O times remain reasonable. Entire projects, no matter how large should save as quickly as the card interface will allow. File save times should not be bound by cumbersome manipulation of internal data structures.
Iām optimistic that this one will be found and squashed. It SHOULD be a rather high priority.