I have noticed that as my project grows in the Play, with an increasing number of patterns added, that the time to copy/paste a pattern has increased significantly; it now takes minutes for a single pattern to be copy/pasted. Has anyone else experienced this?
I assume that under the hood, the copy/paste functionality for some reason must copy/paste every pattern (otherwise, why would the copy/paste time grow with an increasing number of patterns?). Can anyone verify that this is the case? It seems like a software design flaw if copy/pasting one pattern somehow implicates every other pattern.
Same issue here only worse. Projects with several rows of patterns takes in some cases over 30 minutes to save. I have a very fast SD card 200mb write speed. Why should pattern copies and project saves take so excruciatingly long?
Play is fantastic!.. until you start to grow your project size. I have a project with 100+ patterns which takes over 45 minutes to save. Thatās not a typo. Even after purchasing a super fast [200mbps] SD card, there is no difference. It takes a fraction of the time to copy the entire contents of the drive from the computer to the SD card. What is going on here?
Try it for yourself. Go to pattern mode and copy patterns till you have about 3 rows filled. Once you start to get to more than 3 rows (36+) patterns you will notice each pattern copy takes longer - up to a full minute. And then the long save time for the project increases as well. Project open operations are also excruciatingly slow. Iām using an ultra fast speed SD card - 200mb/s write speed. I can copy the entire contents of the SD card 4x faster than the project save time. I feel this is a CRITICAL impact for either live or production. If Iām working with a client and I wont be able to recommend using Play for the session because of these excruciating wait times. This issue must be resolved because users will eventually test the limits of the device and these super long wait times will be a deal breaker.
A suggestion to the developers might be to use pointers to existing patterns instead of copying them to yet another location. That would be both faster and conserve storage space. Of course if an existing pattern is modified and becomes another new pattern, then that wouldnāt apply.
I can confirm that an entirely unique instance is created with no relative link to the original. This could be useful, but it might be cool to have an option during copy such as ālink to original?ā This would be more in line with what Iām attempting to do which is create multiple variations for each row of a track and simply point the sequences to those variations. On some tracks I have up to 16 variations. My guess this has something to so with sample management because the project files themselves are tiny. I do a ton of troubleshooting in my regular IT work and Iām going to drill down like Sherlock Holmes and ultimately find the culprit. Mark my word.
I am a retired software engineer, mostly doing firmware and kernel, and driver work. Since we used C, C++, and some assembler when necessary, we had to be cognizant of code efficiency and tended to these issues. The Tracker and Play are embedded devices with similar restrictions. I donāt know what language(s) are used in their development, so it may not be practical to be relying on pointers in these cases. But if they can, then that should be a practical approach keeping one instance of sample data in one place referenced by pointers in any number of projects.
The best way to drill down into the problem is to understand the source code so one can understand any limitations imposed that would define how the code needs to function in this environment. I doubt that Polyend has any plans to provide source code to anybody without an NDA.
The issue seems to be related to project size. 100% on your assertion that viewing the code would be ideal. Still, if I can determine that the issue is repeatable and which specific conditions are present when it happens, will speed up the efforts by Polyend to find perhaps a needle (anomaly) in the haystack (code.)
Thanks for your efforts. I believe that if you can nail down exactly what is happening from a user perspective that could go a long way toward helping Polyend find a solution.
From some initial testing it looks very much related to using variations. I have a project with only 50% sample memory used and 3 midi tracks. On 3 of the audio rows I have 12-16 variations and same with midi tracks. Until I added the variations, copies were super quick and saves happened in less then 60 seconds. In the video I am starting to copy patterns and with each copy the wait time gets longer. Now granted I counted out the seconds - not entirely accurate - but it is plain as day by the 12th copy the wait time increases and nothing has been added in the meantime. Then I do a save operation which takes quite a while. Iām already at the threshold where the issue is exhibited and if I continue grow the project, the wait times will continue to increase. Honestly, this isnāt even beginning to āpush the limitsā of a project and this bug is a critical one.
Would be good if some of you kind folks would try to replicate the issue before I submit a bug report.
Yeah, it shouldnāt be doing that, will look into this further and get back to you. Iām confident it is a fixable issue. Iāve noticed some memory cards load slower than others but nothing this slow.
Next time (or maybe still this time) you can submit the same bug report here on Bug which makes the report and the team updates visible to everyone. Just a suggestion, you have already provided a lot of information here!