Unsaved patch indicator
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...
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...
- Attachments
-
- Wink.gif (1.04 KiB) Viewed 3193 times
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
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
- Namahs Amrak
- Posts: 609
- Joined: 17 Jan 2015
- Location: Australia
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.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
My Words are my ART
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?
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.
Budapest, Hungary
Reason 11 Suite
Lenovo ThinkPad e520 Win10x64 8GB RAM Intel i5-2520M 2,5-3,2 GHz and AMD 6630M with 1GB of memory.
- Namahs Amrak
- Posts: 609
- Joined: 17 Jan 2015
- Location: Australia
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.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 Words are my ART
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.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 personally like the idea, even though I usually build my sounds from scratch.
Cheers!
Fredhoven
Fredhoven
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.
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.Namahs Amrak 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.
Selig Audio, LLC
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.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
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...
That's another reason I'd find it useful.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.
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).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.
To avoid confusion, another symbol would be fine.
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.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).
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.
I know... hows about this? ≠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.
- Attachments
-
- change-example.jpg (29.25 KiB) Viewed 3278 times
joeyluck wrote:
Not sure if folks would complain that it looks too much like an asterisk...?Pepin wrote:
Sure, that would be perfect
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...
I said it could be some bold type, or cursive type that indicates the changes...les intrusive than any simbol I thinkPepin 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.
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 seemed to have missed that as well... It is a good point/suggestion.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
- Namahs Amrak
- Posts: 609
- Joined: 17 Jan 2015
- Location: Australia
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.
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.
My Words are my ART
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.
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.
(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.
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.
- JiggeryPokery
- RE Developer
- Posts: 1176
- Joined: 15 Jan 2015
Why would you want to save that many patches of slightly altered presets?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.
/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.
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.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.
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.
-
- Information
-
Who is online
Users browsing this forum: No registered users and 10 guests