I recently discovered that the Play/Play+ can load samples from the Export folder back into any project’s Sample Pool!
This amazing capability opens up Play to:
Rendering layered sounds into complex, textured samples that don’t require multiple tracks. Combined with Sample Volume, Start, End, Attack, Decay, Filtering, Distortion, etc. used across multiple tracks/sounds this provides a hidden 8-oscillator synth (even on the OG Play) for creating new complex sound samples. It’s not all that different from the PCM layering synths of the 90’s and allows for sound design techniques not available in many synths like staggering, repeating and reversing sonic elements of the sound.
Re-tuning samples that aren’t originally tuned to C. You can already use samples that were captured at other pitches by manually adjusting their pitch but they won’t work with with the Randomizing and Scale features of Play. Using this method, simply adjust the pitch of the sample to C and export it!
True sample trimming. If only a small portion of a large sample is needed in a project, trim and export the small segment to conserve sample pool memory.
Creating chord samples to conserve polyphony
Layering effects like differing delay lengths
rendering 100% wet sounds which the Play normally does not allow for. Done by importing the Reverb or Delay stems. Want a cowbell lost in a cave? No problem.
Rendering whole patterns to a single sample “loop” greatly increasing the apparent polyphony of the Play - obviously within the limits of the Play sample memory.
It’s really a game changer IMO. Using this technique the Play OG is no longer a playback-only device limited to its sample library. It’s fully capable of sampling its own output to trim and even synthesize new sounds and loops!
I think many users are unaware that this is even possible. The remaining issue is that two simple file operation features are needed to cleanly complete this resampling feature by avoiding external file operations.
I now have a project called “Sampler” where I can load in samples across multiple tracks, trim and manipulate them, trim the overall pattern length to where the sound stops and export the result. The problem is that multiple uses of the Export feature rapidly create a total MESS of exported folders and samples. This makes it all that much more obvious that these machines desperately need a DELETE capability and for that matter the ability to rename samples in the Pool so a project doesn’t end up with a bunch of samples called master or reverb.
With DELETE and RENAME added to complete this “resampling” feature, it would add a whole range of convenient, creative capabilities to the Play series that currently require tedious file management on a separate computer.
Hey Polyend… This is very low-hanging fruit that would result in a significant marketable feature!
Why (re)posting this as a project export solution, instead of the wish / feature request to which you’ve also posted this workaround?
The suggested sample export / rendering feature seems to be much more straightforward. And yes, next to that some decent file management would be very welcome, too. Being it directly on the device itself or by connecting it via USB to a computer (screen, keyboard, etc.).
I agree that rendering to the Sample pool or a specific folder in Samples would be even more streamlined. It would also require additional code. The point of this post is to bring attention to an already available, though largely hidden, feature that many users seem unsurprisingly unaware of. Polyend makes no mention of this capability on the product page even though it arrived with firmware 1.1.0. It opens up a whole range of creative possibilities that simply aren’t possible otherwise.
Adding DELETE and RENAME are from a software perspective very simple. They already have the file mechanisms in the code. File deletion simply isn’t exposed to the user except indirectly in the “Delete Unused Samples” feature. Renaming samples in the pool isn’t allowed though renaming sample pool folders is. It would be a simple substring replacement operation and the ASCII keyboard is fully implemented already.
I’m simply trying to highlight a win-win scenario for Polyend and Play users. Resampling rendered output is a HUUUUUUGE feature that goes unknown to most users and potential buyers. A couple simple additions to the code would complete the feature so that users wouldn’t end up with ever-growing collections of export folders and Sample pools full of repeated names.
There is no good reason to do any of this off-device.
Very good reasons to add these file operations are not only convenience and workflow speed but also device longevity. Micro SD slots are fragile and most are not designed for routine insertion cycles. I’ve seen SD slots with their tiny internal pins bent by a hurried, sloppy card insertion. Bend a pin on the Play SD slot and the device becomes a useless brick. I treat the uSD card like an egg while gently inserting it into the Play. My preference is to do that as infrequently as possible.
They did mention it in the linked topic, and yes maybe they could write a separate instruction for it. But, it’s still a workaround that’s making use of an incomplete feature… so I do think the code for a ‘render to…’ feature is already in place. Because it’s basically the same as what they’re already doing when rendering separate stems from an entire project. So at least the biggest chunk or heavy lifting is already there.
Why I’m suggesting USB should be made available first, is because it needs less coding and UI development to implement reliable file management (copy, paste, delete, rename, move, etc.) and processing on the device itself. Implementing a standard protocol for mounting and accessing the SD Card as a host drive should be much easier. I think the actual file management and processing should be done on the guest OS.
USB file access would be great, no question. I don’t think it requires less coding. I’m quite sure it would require more and a significant amount of QA time as well. There would be mode-switches required to go from USB MIDI to File Transfer mode and back as well.
Even the Render-To feature should be simple and more direct as you note because the framework is clearly in there.
I disagree about doing all this on a host computer only. For many, if not most, the whole point of a portable device like the Play is to escape the computer, otherwise they would be sitting in front of their DAW. I would like to avoid using my PC as much as possible when working with devices like Play so being able to delete and rename files on the Play is still the best solution IMO.
remove unused samples doesnt delete samples from the card it just removes unused samples from the memory of the actual project
this is one of the biggest pains ,when u chose samples for a new project about an hour long and then you dialed the wheel one bit to far and select remove all unused samples . without an confirmation everything is away
It does delete samples from the card. It only deletes the files from the sample pool of the working folder on the card not from the Samples library. As I understand it, the Play does not keep an entire project in memory. The working folder holds all elements of the project and they are accessed as needed. This project-mirroring approach is part of the reason that saving large projects can be a slow affair on the Play. The full contents of the working folder must be individually read and rewritten elsewhere on the card. I still think this can be optimized substantially though.
My point was that file deletion is actually implemented on the Play, we just need to be able to use it in a more generalized way.
Agreed, “confirmation on deletes” would be a good global option so that people could avoid costly mistakes if they wish.
I just stumbled on this myself recently and it has become a vital part of my workflow. It seriously gives the sampling power of this thing a real boost, along with the convenience of being able to export full tracks or stems. But being able to rename and delete files would be huge. That and a “move file” function would make the play so much more immersive. Tbh, my top three wishes would be this, more in-depth sample editing, and trigless trigs. The sample side is so close to being an absolute beast. If it only had a few more tune-ups like this, it’d be nearly perfect.
“Triggless trigs” would be great but falls outside the notion of each step being a complete sound event which seems to be the basic concept of “pick and place”. I have my doubts we will see that feature.
Adding the file operations though is easy and allows the Play to act as a more complete composition environment including the ability to create new sounds at will.
Oh definitely. It’s more or less just me being hopeful for some sort of automation function being implemented, I’m not going to hold my breath over it though as I have a workaround, albeit a slow process.
The file operations, though, just make sense all around. I love how adaptable the play is to workflows, but not having this feature makes using the sample side clunky for no reason. Hopefully its something they consider for the next update🤞
i think that funtions that are not going to be implemented could be added as some type of , synth, plugin . all the synths in play are just a file that you copy to the sd card and so i think if theres a , trigless trigs plugin, which u can load into a synth slot where you can set steps and chose a parameter to sequence with that . also for reverb and delay settings there could be a synth plugin where u can change parameters for reverb and delay .ive got lots of other ideas for such plugins but i dont know igf this even is possible
It occurred to me that this technique also allows re-tuning samples that aren’t originally captured at C. I have some nice samples that aren’t pitched to C so exporting them with the pitch adjusted to C allows using them with the Randomization and Scale features of Play.
Being able to do this quickly and conveniently on the Play would be a huge boost by opening up a much wider range of publicly available samples. For that, we just need a couple little file system features.
