ReasonTalk.com

Reposting this from the Props forum. It's a small thing, but it would improve patch management significantly IMO...

An asterisk in front of the patch name if the patch has been changed:
 
E.g.
After loading patch:

 
After changing some parameter:

 
 
It would disappear after you save the new patch somewhere and reappear if you change that one, etc...

I like it!

D.

Hi,

I'm curious - what would this asterisk mean to you as a user? That you need to save the patch because you have made changes?

/ LudvigC

Just like saving photoshop changes. I mean yes, that the patch is not the original, that changes have been made.

But in Photoshop, you *need* to save the document to keep your changes.

In Reason, all settings on a device panel are included in the saved song. Saving an edited patch is only needed if you're really happy about the changes you have edited and want to use the edited patch in other songs.

Personally, I typically load a patch as a starting point, and more often than not tweak some parameters depending on the song. I have no real need to save a new version of the patch just because I've changed the filter cutoff or release time or something - it's all song-specific.

I guess I'm just wary that I would get a number of asterisks showing in my song, which for me would just increase the visual stress (the program is asking me to do something, which isn't actually needed).

/ LudvigC

LudvigC wrote:Hi,

I'm curious - what would this asterisk mean to you as a user? That you need to save the patch because you have made changes?

/ LudvigC

If I'm understanding the OP correctly, it would serve the same purpose as the asterisk in an unsaved project file. It's a signal to the user that the project (or in this example, a patch) needs to be saved.

 

Ok fair enough
I get your point.When you save your song the patch that you changed still changed.
What I thought with this request is, that when I open a song and the thor patch "epic" has an asterix "epic*" it means I did a change to it when I did the song...That it is no more the original.
Because maybe I cannot remember if I did change the patch or not.
I, and that's maybe just me, not always change the preset patches...sometimes I get inspired by the original sound by itself, although most of the time I do as you said.
Maybe it would be less stressful just to change the type to cursive or bold or something when the patch is not the original.
What do you think?

Well it is something I would like to have as a feature due to the way the new browser works so I do not loose a modified patch after browsing. If you have any plans, I hope you do, to somehow resurrect the beloved "preview" i.e. Cancel capability of the browser many of as misses, than I would say let us see how it will work and get back to the asterisks afterwards.

tt_lab wrote:Ok fair enough
I get your point.When you save your song the patch that you changed still changed.
What I thought with this request is, that when I open a song and the thor patch "epic" has an asterix "epic*" it means I did a change to it when I did the song...That it is no more the original.
Because maybe I cannot remember if I did change the patch or not.
I, and that's maybe just me, not always change the preset patches...sometimes I get inspired by the original sound by itself, although most of the time I do as you said.
Maybe it would be less stressful just to change the type to cursive or bold or something when the patch is not the original.
What do you think?

My initial thought was 'why bother' but I'm now actually thinking it would be a great idea. Sometimes I navigate through patches with the arrow buttons (ie no browser open) out of curiosity, and if I'm using a tweaked patch I would lose it. An asterix would be a good reminder to take a moment to save it before proceeding. So, good suggestion.

LudvigC wrote:But in Photoshop, you *need* to save the document to keep your changes.

In Reason, all settings on a device panel are included in the saved song. Saving an edited patch is only needed if you're really happy about the changes you have edited and want to use the edited patch in other songs.

Personally, I typically load a patch as a starting point, and more often than not tweak some parameters depending on the song. I have no real need to save a new version of the patch just because I've changed the filter cutoff or release time or something - it's all song-specific.

I guess I'm just wary that I would get a number of asterisks showing in my song, which for me would just increase the visual stress (the program is asking me to do something, which isn't actually needed).

/ LudvigC

I think the idea is to have a reminder that if you change a patch, and then try different patches later on, you won't be able to get that same sound, by loading the unmodified patch.
I personally like the idea, even though I usually build my sounds from scratch.

LudvigC wrote:Hi,

I'm curious - what would this asterisk mean to you as a user? That you need to save the patch because you have made changes?

/ LudvigC

Namahs Amrak wrote:
If I'm understanding the OP correctly, it would serve the same purpose as the asterisk in an unsaved project file. It's a signal to the user that the project (or in this example, a patch) needs to be saved.

Namahs Amrak wrote: 

I think Ludvig's point was the opposite of what you stated - that a patch DOESN'T need to be "saved" in Reason. So an indicator that says "This will be lost if you don't save it" is actually inconsistent with the rest of the interface. Better to use a symbol which doesn't already have a very clear connotation associated with it IMO.

I can see the point that it would be handy to know if the patch was CHANGED - but the asterisk indicates something different in Reson, so a different symbol would be needed IMO.

LudvigC wrote:Hi,

I'm curious - what would this asterisk mean to you as a user? That you need to save the patch because you have made changes?

/ LudvigC

That's part of it but not the only reason. In my case, I keep my best patches saved in a folder structure and reuse them in multiple songs, often with significant tweaks. And I don't always think to save them out immediately.

So suppose I like a patch I find when revisiting a song. I might want to save it out to a separate file. But if it has the same name as a patch I've already saved, it's not immediately clear whether or not it's a duplicate. In this situation, I have to cancel the save and load the patch that's already saved under that name to check if it's identical.

Also...

Gaja wrote:I think the idea is to have a reminder that if you change a patch, and then try different patches later on, you won't be able to get that same sound, by loading the unmodified patch. I personally like the idea, even though I usually build my sounds from scratch.

That's another reason I'd find it useful.

selig wrote: I can see the point that it would be handy to know if the patch was CHANGED - but the asterisk indicates something different in Reson, so a different symbol would be needed IMO.

Actually, that specific meaning of the asterisk is a Windows thing, not a Reason thing. Since I'm under OS X, I wasn't really thinking about that when making the request (in OS X, the "changed" indicator is a black dot on the "close" button of the main window).

To avoid confusion, another symbol would be fine.

LudvigC wrote:I guess I'm just wary that I would get a number of asterisks showing in my song, which for me would just increase the visual stress (the program is asking me to do something, which isn't actually needed).

This is a good point. If there was a way to give such an indication without implying that an action is required, that would be preferable.

selig wrote: I can see the point that it would be handy to know if the patch was CHANGED - but the asterisk indicates something different in Reson, so a different symbol would be needed IMO.

Pepin wrote:
Actually, that specific meaning of the asterisk is a Windows thing, not a Reason thing. Since I'm under OS X, I wasn't really thinking about that when making the request (in OS X, the "changed" indicator is a black dot on the "close" button of the main window).

To avoid confusion, another symbol would be fine.

I know...  hows about this?  ≠

   

joeyluck wrote:   

Sure, that would be perfect

joeyluck wrote:   

Pepin wrote:
Sure, that would be perfect

Not sure if folks would complain that it looks too much like an asterisk...?
But it does imply "not equal to." And it wouldn't bother me.

Something else that comes to mind would be something a little more subtle like having the font become bold...

Pepin wrote:
This is a good point. If there was a way to give such an indication without implying that an action is required, that would be preferable.

I said it could be some bold type, or cursive type that indicates the changes...les intrusive than any simbol I think

Pepin wrote:
This is a good point. If there was a way to give such an indication without implying that an action is required, that would be preferable.

tt_lab wrote: I said it could be some bold type, or cursive type that indicates the changes...les intrusive than any simbol I think

I seemed to have missed that as well...  It is a good point/suggestion.

Personally, I think Ludvig is making too many assumptions on how people should work. There's no one set workflow that we need to adhere to, according to what Propellerhead think is best for us. It's the limitless possibilities of the Reason platform that encourage a personal workflow style that suits the individual best. While he may not see any worth to some of the suggestions, there are a number of scenarios that might call for what the OP is suggesting (whether his suggested execution is the best option or not).

As I mentioned, If I tweak a patch, then happen to scroll through presets using the arrow keys on a device, I will lose those presets. An indicator that the preset has been changed would solve this from happening. It's all well and good to say that when saving a project file, the settings are changed too, but what if we are spending a week working on a song? I'm not necessarily going to remember what I did to a device seven days ago.

The other aspect is, there are those who might have found 'that' sound they have been trying to achieve for months, that can be used across a whole range of other projects. Again, after a duration of time has passed, we can't be expected to remember every tweak we made, and if we didn't happen to save it as a new patch, then it's likely to be a troublesome exercise to re-open that file, find the instance of that tweaked file (a tough job if you have 20 of them in a project) and preserve it for later. With some indication that changes have been made, it would enhance the ability to perform some simple housekeeping by easily glancing at all the devices in a project before closing, seeking out the marked patches, and making some pre-close saves.


Although to clarify, I don't think it's a high-priority enhancement to the platform. If it can be achieved easily enough then great, but there are far more pressing matters that need to be remedied.

I love this idea and completely understand what you are talking about.
I see how "*" would be very confusing to a lot of people and make them feel like they must save it, it would have to be a different symbol or maybe have a blue digital tinted color instead of the green.

If we were to use another symbol than an asterisk, I would suggest a colon. It's fairly unobtrusive, doesn't look like an asterisk, and it's a forbidden character in filenames, both in Windows and in Mac OS, to avoid confusion.

  (yes, colon is that big in the patch selector font.)

Or, we could get a bit more complicated and dim the patch display down a bit when something has been changed, to indicate that what it says isn't entirely "true" anymore.

 

One can still see what patch the current settings are based on, but it should be fairly clear that something has happened. Technically I guess it could be done by rendering the text with about 50% opacity (that's what I did).

I wonder, though, if any of our ideas would be possible to implement without every RE developer having to recompile their Rack Extensions. If we're lucky the file handling logic is separated from the internals such that the Props could tweak the file handling independently.

Just to be clear, I'm not usually suffering from the lack of an altered patch indicator, but I have butterfingered some patches I thought I had saved, and, well, an, indicator might have helped a bit.

I'm all for anything like Pepin is suggesting (something as an indicator to let me know a patch has been changed).  I think most people particularly find the need for it in Reason 8 because you cannot simply 'cancel' after you browse for other patches.

What I find interesting however, is that in the other forum when I would suggest to people that they save their patches before they go on a browsing spree,  9/10 folks would reply to me, "Why would I want to save that many patches of slightly altered presets?"  

Which I think brings us to something else people have been asking for—some sort of patch preview feature in some form or another.  I think ultimately that would help tremendously with this same issue.

joeyluck wrote:I'm all for anything like Pepin is suggesting (something as an indicator to let me know a patch has been changed).  I think most people particularly find the need for it in Reason 8 because you cannot simply 'cancel' after you browse for other patches.

What I find interesting however, is that in the other forum when I would suggest to people that they save their patches before they go on a browsing spree,  9/10 folks would reply to me, "Why would I want to save that many patches of slightly altered presets?"  

Which I think brings us to something else people have been asking for—some sort of patch preview feature in some form or another.  I think ultimately that would help tremendously with this same issue.

Why would you want to save that many patches of slightly altered presets?

/ducks

No-one has ever asked for a patch preview (or pre-load) feature. It was part of Reason for as long as I can remember. Propellerhead CHOSE to remove that feature. The feature request was to take it out. It's gone. It's awful, poor decision-making, it's a massive and backwards, workflow-killing step, but that's what PH chose to do.

JiggeryPokery wrote:Propellerhead CHOSE to remove that feature. The feature request was to take it out. It's gone. It's awful, poor decision-making, it's a massive and backwards, workflow-killing step, but that's what PH chose to do.

As far as I know, but I may be wrong, the "preview" of the old browser wasn't ever an intended, or perhaps even conscious, actual feature, but rather a very useful side-effect of how the old browser managed memory.

Being a software developer myself, I have also inadvertently and unknowingly created a useful side-effect or two, and been surprised when my users have regarded the behavior as a feature.

Say I did an ugly hack where I temporarily stored something on clipboard, and then forgot to tidy up when done. I'd consider myself to have caused a bug, while my users enjoyed my clever "auto-copy feature". I made that example up, because reality is more complicated, but you get the point.

Perhaps we shouldn't just presume PH deliberately chose to kill a useful feature. I think it's conceivable they never saw it as anything more than a side-effect of tidying up a canceled browsing dialog, and was genuinely surprised when we started batch about it.

That said, now when that behavior is gone, we should - just as we are - keep asking for it, but let's not attribute to malice that which can be adequately explained by ignorance.