Just wondering how others are handling the issue of the MC-707 lacking any actual patch storage as it's quickly becoming quite the headache for me.
At current, can't say I've come up with much more than going out of one's way to name every clip in a project and making sure those clips reflect both the type of patch held in the clip as well as whatever name one might have named the patch held on the clip. (unfortunately, this takes away being able to name clips by any other descriptors)
The idea of coming up with a Project(s) that literally does nothing but hold patches has also come to mind. Would be annoying as mad to setup and maintain in any sort of sensible order structure, but meh, it could at least act as a means of having one localized place for browsing through stored user created patches.
Such have been my only ideas so far....
very interested in what anyone else may have come up with.
How Are Others Handling the Lack Of Patch/Program Storage?
-
- Posts: 111
- Joined: 19:43, 2 January 2018
Re: How Are Others Handling the Lack Of Patch/Program Storag
I'm just thinking out loud here, because I haven't sat with this issue for long; what if we created an empty template project from which we always created our new Projects, essentially by doing a "Save as..."; in this template project Track 8 (for example) becomes our 'custom tone storage bank', where we keep clips with the sound only, and the clips names are the patch names.A23P wrote:Just wondering how others are handling the issue of the MC-707 lacking any actual patch storage as it's quickly becoming quite the headache for me.
At current, can't say I've come up with much more than going out of one's way to name every clip in a project and making sure those clips reflect both the type of patch held in the clip as well as whatever name one might have named the patch held on the clip. (unfortunately, this takes away being able to name clips by any other descriptors)
The idea of coming up with a Project(s) that literally does nothing but hold patches has also come to mind. Would be annoying as mad to setup and maintain in any sort of sensible order structure, but meh, it could at least act as a means of having one localized place for browsing through stored user created patches.
Such have been my only ideas so far....
very interested in what anyone else may have come up with.
Then we can copy from that 'storage bank' over to other tone tracks and play the parts we want with the recalled sound.
Limitations I can see right off:
1) We would only have storage for 16 custom sounds in the 16 clips available in Track 8.
2) If we create a new sound for a new project we would have to figure a way to populate that sound back into the template. (Doing a kind of reverse "Save as.." might work, where we copy the new tone over to Track 8 in an empty clip, name it and then delete all the other tracks except 8 and save it again overwriting the previous template)
3) We would need to always build off the template and only delete the "tone storage track" at the last possible minute when we have used all the other tracks.
I'm sure there are other limitations I'm not picturing yet.
It's not much, but it's a little bit of something, maybe?
kS
Re: How Are Others Handling the Lack Of Patch/Program Storag
There's been two methods that I've looked to imploring, but with limited feelings of success thus far.
The first was one I came up with, which was to simply create a "Patch" project and then organize different sorts of patches by named clips held on tracks. Ala Track 1 is nothing but drum kits, Track 2 is nothing but basses, Track 3 is nothing but leads, Track 4 is nothing but pads, etc.
The channel names can even be conveniently named to reflect the types of patches they hold (which might alleviate having to name every single clip held in that category a wee bit).
One limitation to this method is that each track can only hold 16 clips AND if one lane gets filled up prior to the others (which is bound to happen) a whole new Project needs to be created to continue on with patches of that sort.
The other method is one I heard elsewhere of someone doing. In this other method, Projects for specific types of patches are simply created. So one Project might just be "Pads", another "Drum Kits", another "Basses", etc.
The primary benefit I see to this other method is that the limitation for a patch type expand from 16 to 128. The draw back is that it creates more immediate Project clutter.
Such said, I find the Project Template that begins with a reserved Track of basically "favorite patches" (given the 16 limit) interesting.... biggest draw back to it I immediately see is that it sort of calls on one to make an immediate timbrality sacrifice, but I can none the less see it coming in potentially handy at times.
Cool idea there @jicamasalad
The first was one I came up with, which was to simply create a "Patch" project and then organize different sorts of patches by named clips held on tracks. Ala Track 1 is nothing but drum kits, Track 2 is nothing but basses, Track 3 is nothing but leads, Track 4 is nothing but pads, etc.
The channel names can even be conveniently named to reflect the types of patches they hold (which might alleviate having to name every single clip held in that category a wee bit).
One limitation to this method is that each track can only hold 16 clips AND if one lane gets filled up prior to the others (which is bound to happen) a whole new Project needs to be created to continue on with patches of that sort.
The other method is one I heard elsewhere of someone doing. In this other method, Projects for specific types of patches are simply created. So one Project might just be "Pads", another "Drum Kits", another "Basses", etc.
The primary benefit I see to this other method is that the limitation for a patch type expand from 16 to 128. The draw back is that it creates more immediate Project clutter.
Such said, I find the Project Template that begins with a reserved Track of basically "favorite patches" (given the 16 limit) interesting.... biggest draw back to it I immediately see is that it sort of calls on one to make an immediate timbrality sacrifice, but I can none the less see it coming in potentially handy at times.
Cool idea there @jicamasalad
Re: How Are Others Handling the Lack Of Patch/Program Storag
Also using a specific project so save patches but it is a pain as you are working on your current project and come up with a patch/drumkit/... and then want to save it. Its not like switching projects is an immediate action so one has to go to the other project, import form the current project, save and then go back. It's way too much hassle.
Roland is doing great with updates, why not introduce the ability to save sounds (tone/drum/drumkits) on the SD card? For tones it seems very simple, they already have the 'sounds' that can also be downloaded from Roland cloud manager, so why not save sounds from the MC-707 itself? (they do miss the preview function!!) Next step is for drums.
I hope this gets implemented. The MC-707 seems like it is hitting a lot of homeruns, just a couple of things to fix :)
Roland is doing great with updates, why not introduce the ability to save sounds (tone/drum/drumkits) on the SD card? For tones it seems very simple, they already have the 'sounds' that can also be downloaded from Roland cloud manager, so why not save sounds from the MC-707 itself? (they do miss the preview function!!) Next step is for drums.
I hope this gets implemented. The MC-707 seems like it is hitting a lot of homeruns, just a couple of things to fix :)
Re: How Are Others Handling the Lack Of Patch/Program Storag
Actually, the sound packs don't get treated like the preset tones either in as much that there is no auto-previewing what the tones are like. Rendering the process of accessing them little different than just loading up a project clip that was used in place of the lack of ability to save/export "tones"/patches.Senthrax wrote:they already have the 'sounds' that can also be downloaded from Roland cloud manager, so why not save sounds from the MC-707 itself? (they do miss the preview function!!) Next step is for drums.
For what it's worth, the Fantoms seem to have their own set of patch storage headaches at current and from the sound of things, seems to come off of as the lesser of patch headache evils between the two.
But for sure.....
the "tone"/patching system can def use some help.
And seems not just for the 707, but seems likely the Zen hardware line as a whole.