Is it me or is the Reason 'find missing files' window useless?
-
- Posts: 124
- Joined: 24 Mar 2015
I load a song. I get a message that it can't find samples from a refill that I must have moved. So I point it to where it is in the browser, select 'search folder' and ... it searches the whole computer
So I'm sat there waiting for it to scan every Windows system file, everything in my iTunes folder and every sample in my collection in the hope that it might eventually find what I've just pointed it at, not able to get on with anything.
With Cubase, you could point it at where one sample was and then it would ask if you wanted to search in that location for the rest too. Logical and efficient.
So am I doing something wrong or is it really as useless as it appears?
So I'm sat there waiting for it to scan every Windows system file, everything in my iTunes folder and every sample in my collection in the hope that it might eventually find what I've just pointed it at, not able to get on with anything.
With Cubase, you could point it at where one sample was and then it would ask if you wanted to search in that location for the rest too. Logical and efficient.
So am I doing something wrong or is it really as useless as it appears?
Last edited by CaptainBlack on 02 Aug 2018, edited 1 time in total.
- kuhliloach
- Posts: 881
- Joined: 09 Dec 2015
I agree it's non-intuitive and barely functional. It seems you need to double-click in the browser, not single-click, then return to the Find Missing Files window and try again. I hear you.
-
- Posts: 124
- Joined: 24 Mar 2015
Double click! Well, clear as mud but that helps a little. Thanks.
- Exowildebeest
- Posts: 1553
- Joined: 16 Jan 2015
Yeah, I've always found it confusing as hell as well. One of those areas of Reason that's poorly designed.
I was going to say "it's just you" but then I saw the comments.. lol
You have to browse to the containing folder, inside of Reason's browser window (while it's actively in the search mode ie when the border is orange).
Then you open that folder inside of Browser.
Then you click search folder.
It searches whatever folder that has been opened in the Browser.
It, very quickly, finds the material as long as said material was in the selected folder. The only trick is you have to have that folder opened in the browser via the missing files search function. Not much to it really. I've found that it works pretty well.
You have to browse to the containing folder, inside of Reason's browser window (while it's actively in the search mode ie when the border is orange).
Then you open that folder inside of Browser.
Then you click search folder.
It searches whatever folder that has been opened in the Browser.
It, very quickly, finds the material as long as said material was in the selected folder. The only trick is you have to have that folder opened in the browser via the missing files search function. Not much to it really. I've found that it works pretty well.
What puzzles me is that I need to locate the sounds every time I open my project. It should be able to remember the last location.sublunar wrote: ↑03 Aug 2018I was going to say "it's just you" but then I saw the comments.. lol
You have to browse to the containing folder, inside of Reason's browser window (while it's actively in the search mode ie when the border is orange).
Then you open that folder inside of Browser.
Then you click search folder.
It searches whatever folder that has been opened in the Browser.
It, very quickly, finds the material as long as said material was in the selected folder. The only trick is you have to have that folder opened in the browser via the missing files search function. Not much to it really. I've found that it works pretty well.
Also that message "All sounds have been found!"... perhaps could be toned down by removing the exclamation mark.... sounds like it achieved something major
- Exowildebeest
- Posts: 1553
- Joined: 16 Jan 2015
jappe wrote: ↑03 Aug 2018What puzzles me is that I need to locate the sounds every time I open my project. It should be able to remember the last location.sublunar wrote: ↑03 Aug 2018I was going to say "it's just you" but then I saw the comments.. lol
You have to browse to the containing folder, inside of Reason's browser window (while it's actively in the search mode ie when the border is orange).
Then you open that folder inside of Browser.
Then you click search folder.
It searches whatever folder that has been opened in the Browser.
It, very quickly, finds the material as long as said material was in the selected folder. The only trick is you have to have that folder opened in the browser via the missing files search function. Not much to it really. I've found that it works pretty well.
It should remember if you re-save the file.
Over time, I've learned to make friends with the "Find Missing Files" dialog, and usually get the results I need. But I have one older song that prompts me for a "missing" NN-XT patch + samples, even though I navigate to the exact location of the refill it wants, expand the refill and can see the "missing" files in Reason's browser. But for whatever reason, the Find feature is completely blind to this refill.
Aside from that one quirky example, it usually finds missing files without any problems.
Aside from that one quirky example, it usually finds missing files without any problems.
wreaking havoc with since 2.5
https://soundcloud.com/nekujak-donnay/sets
https://soundcloud.com/nekujak-donnay/sets
Yep, it is mostly useless. Even when you know which refill it is in it can't find it. Many times I've resorted to a basic windows explorer search and found the file in seconds and navigated through the reason browser to the file and any search take ages and ages.
Needs a total revamp.
Needs a total revamp.
Tend the flame
Yes, it's useless, that's why I am slowly doing away with refills.
- CephaloPod
- Posts: 268
- Joined: 16 Jan 2015
This.kuhliloach wrote: ↑02 Aug 2018I agree it's non-intuitive and barely functional. It seems you need to double-click in the browser, not single-click, then return to the Find Missing Files window and try again. I hear you.
2011 iMac i7; 24 GB RAM; OSX Sierra; Nektar LX 49; MOTU Microbook
Reason/Logic
Reason/Logic
The search on Reasons browser is near useless to be honest. I wonder if it's ever going to be fixed. You have to manually locate the folder with the missing samples and open that in the browser, then it searches that open folder. If you tried searching from the top for a sample, you might as well go on holiday for 3 weeks and hope for the best. Windows search is painfully slow but it's like jumping to light speed in comparison.
- JiggeryPokery
- RE Developer
- Posts: 1174
- Joined: 15 Jan 2015
There are two known issues.
If the stored patch or song "loses" the reference to the ReFill name, there seems to be no way to retrieve the sample. How this error occurs in the first place I don't know - possibly opening up an old track in a newer version causes an error. Sometimes the Missing Sounds window only shows the sample names, not the known ReFill name. But Missing Sounds requires the ReFill name in this scenario, even if you can see the same sample name side by side in the browser and the Missing Sounds page, it just won't register.
So for example you have "C:\ReFills\MyGreat.rfl\SampleC#1", where MyGreat.rfl is has the internal name (this is the important bit, the filename is irrelevant) "My Great ReFill 2".
The sample window should have the following details:
Sound = "SampleC#1", Part of ReFill = "My Great ReFill 2"
Now, usually wherever you have MyGreat.rfl stored, you can browse to its sample folder and update it with Replace, even if it moves to "Z:\CrapReFillsIDon'tUseButCan'tEntirelyDeleteBecauseIMightHaveUsed1PatchTenYearsAgo\MyGreat.rfl\SampleC#1"
But what sometimes happens is you get
Sound = "Sample C#1", Part of ReFill = "[blank]".
or, if the internal name changed through, say, a product update and it was an earlier version
Sound = "Sample C#1", Part of ReFill = "My Great ReFill", (note: not "My Great ReFill 2"!)
No amount of clicking will resolve this even where the samples are exactly the same, as for some curious reason it was decided the Missing Sounds can only resolve based on ReFill name, not like-for-like sample name. If the process were entirely automatic, sure, I'd understand that might be needed to prevent scenarios of the multiple uses of the same sample name (i.e. all C#1 patches are called SampleC#1)*, but it's largely a manual process that involves locating the specific sample folder to action the replacement, where each sample name must of course be unique, locking it to the original ReFill name makes no sense, hence why it's a bug. This is why I stopped updating bitley™'s otherwise excellent Fairlight stuff, as he couldn't just pick a product name and stick with it, he changed it as info level each time so each version had to be left installed to access it for legacy stuff.
Secondly, and I reported this years ago though I've not checked recently to see if this was fixed, (fairly sure I reported the first one, but tbh I can't remember so I won't swear to it, as much as I like swearing ) but afaik it is still true in R9: NN-19 is completely börken and never resolves even with the correct ReFill name displayed, if the drive location is different from the original stored value.
Edit: Yup, it is still broken in R9.5 at least. NN-19 won't resolve samples from PinkNoise's Analog Monsters Vol1 in my test case from an old rns file. Only the drive location is different, and you can't manually Replace the samples one at a time with it either.
On the plus side, personally I rarely used NN-19, so that error was infrequent, if annoying.
* looking again, this is complex because Search and Replace can cover multiple folders (and that's pretty good when it works), so this would be a big issue if that was the naming convention used across those folders. So I do get that that level of protection is probably required at an automatic or semi-automatic search and replace level. But the fully manual search and replace by single sample folder should operate replace by like-for-like sample name, regardless of Part of ReFill, whether it's blank or not.
If the stored patch or song "loses" the reference to the ReFill name, there seems to be no way to retrieve the sample. How this error occurs in the first place I don't know - possibly opening up an old track in a newer version causes an error. Sometimes the Missing Sounds window only shows the sample names, not the known ReFill name. But Missing Sounds requires the ReFill name in this scenario, even if you can see the same sample name side by side in the browser and the Missing Sounds page, it just won't register.
So for example you have "C:\ReFills\MyGreat.rfl\SampleC#1", where MyGreat.rfl is has the internal name (this is the important bit, the filename is irrelevant) "My Great ReFill 2".
The sample window should have the following details:
Sound = "SampleC#1", Part of ReFill = "My Great ReFill 2"
Now, usually wherever you have MyGreat.rfl stored, you can browse to its sample folder and update it with Replace, even if it moves to "Z:\CrapReFillsIDon'tUseButCan'tEntirelyDeleteBecauseIMightHaveUsed1PatchTenYearsAgo\MyGreat.rfl\SampleC#1"
But what sometimes happens is you get
Sound = "Sample C#1", Part of ReFill = "[blank]".
or, if the internal name changed through, say, a product update and it was an earlier version
Sound = "Sample C#1", Part of ReFill = "My Great ReFill", (note: not "My Great ReFill 2"!)
No amount of clicking will resolve this even where the samples are exactly the same, as for some curious reason it was decided the Missing Sounds can only resolve based on ReFill name, not like-for-like sample name. If the process were entirely automatic, sure, I'd understand that might be needed to prevent scenarios of the multiple uses of the same sample name (i.e. all C#1 patches are called SampleC#1)*, but it's largely a manual process that involves locating the specific sample folder to action the replacement, where each sample name must of course be unique, locking it to the original ReFill name makes no sense, hence why it's a bug. This is why I stopped updating bitley™'s otherwise excellent Fairlight stuff, as he couldn't just pick a product name and stick with it, he changed it as info level each time so each version had to be left installed to access it for legacy stuff.
Secondly, and I reported this years ago though I've not checked recently to see if this was fixed, (fairly sure I reported the first one, but tbh I can't remember so I won't swear to it, as much as I like swearing ) but afaik it is still true in R9: NN-19 is completely börken and never resolves even with the correct ReFill name displayed, if the drive location is different from the original stored value.
Edit: Yup, it is still broken in R9.5 at least. NN-19 won't resolve samples from PinkNoise's Analog Monsters Vol1 in my test case from an old rns file. Only the drive location is different, and you can't manually Replace the samples one at a time with it either.
On the plus side, personally I rarely used NN-19, so that error was infrequent, if annoying.
* looking again, this is complex because Search and Replace can cover multiple folders (and that's pretty good when it works), so this would be a big issue if that was the naming convention used across those folders. So I do get that that level of protection is probably required at an automatic or semi-automatic search and replace level. But the fully manual search and replace by single sample folder should operate replace by like-for-like sample name, regardless of Part of ReFill, whether it's blank or not.
Thanks... or... However, this is not true, Reason has a fantastic capability of locating stuff inside refills. You can move on and toss the old. Locate the sounds by pointing to the new refill; everything is done automatically. Save the song. Done.JiggeryPokery wrote: ↑06 Aug 2018This is why I stopped updating bitley™'s otherwise excellent Fairlight stuff, as he couldn't just pick a product name and stick with it, he changed it as info level each time so each version had to be left installed to access it for legacy stuff.
Prior to this the refills naturally have to be saved on decidedly excellent spots and those needs to be shortcut'ed to in the Rezon Brausa.
- Faastwalker
- Posts: 2284
- Joined: 15 Jan 2015
- Location: NSW, Australia
Come to think of it I've never had much luck with this function either. I learned to NEVER move anything to get around it. I don't think I've used it for years. But I remember thinking that I must be doing something wrong to need it in the first place or for it to be not working when I did!
I also rarely use Refills these days. Possibly because I kept loosing samples & references to them? I guess it could have been a factor but I wasn't conscious of this at the time. I just thought I was crap at file management, which is certainly a factor in the 'files missing' error when opening a Reason file.
I also rarely use Refills these days. Possibly because I kept loosing samples & references to them? I guess it could have been a factor but I wasn't conscious of this at the time. I just thought I was crap at file management, which is certainly a factor in the 'files missing' error when opening a Reason file.
- JiggeryPokery
- RE Developer
- Posts: 1174
- Joined: 15 Jan 2015
I explained at some depth why it doesn't work, Patrick. So please quit giving people here the Sarah Sanders routine.bitley wrote: ↑22 Aug 2018However, this is not true, Reason has a fantastic capability of locating stuff inside refills. You can move on and toss the old. Locate the sounds by pointing to the new refill; everything is done automatically. Save the song. DoneJiggeryPokery wrote: ↑06 Aug 2018This is why I stopped updating bitley™'s otherwise excellent Fairlight stuff, as he couldn't just pick a product name and stick with it, he changed it as info level each time so each version had to be left installed to access it for legacy stuff.
.[/i]
Speaking soley from extensive experience in Windows, if the ReFill name gets disassociated from the sample, and is thus missing from the missing sample window—and I've no idea how and when this happens, but I've seen it multiple times—you cannot update your samples on reopening that ancient track with a ReFill of a different product name even if it contains exactly the same samples. And NN-19 sample references won't update at all even if the product name is the same. Which bit of that is unclear?
I changed the name of my first two organ ReFills in 2007 (originally they were "Jiggery-Pokery's Combo Compact" etc, and I dumped the "Jiggery-Pokery's" from the internal name of 1.5. Fortunately no-one bought it before that rerelease as I didnt really advertise it, but it's screwed me a few times reopening my own old tracks of the era. I had to dig around my external hard drives and find the originals: Reason simply would not see the samples in the 1.5 release, which themselves had not changed at all. I'd do a video, but if you watched it you wouldn't then have the decency to acknowledge you're wrong. And sorry to be harsh, but you are.
So 2007 was the last time I changed a product name at info.txt level.
That was in 2007, Patrick. You're still doing it and potentially forcing your users to have multiple versions of the same product in order to reliably open old song files without any hassle. If you've really not had this issue, or don't mind manually reconstructing your patches on opening old songs, that's fine: it's possible others have had no issue and I'm totally happy to accept that. But that's no excuse to entirely dismiss the experiences of people who have had issues by telling them their experience is untrue.
- JiggeryPokery
- RE Developer
- Posts: 1174
- Joined: 15 Jan 2015
OK, I'll do a quick video of the NN-19 bug, as this is an rns file I know to not work. I don't have the energy to trawl through loads of old songs and find a specific error for the missing location problem generally, let alone specifically for Fairlight.
But here's what can happen with NN-19 if the ReFill location is in any way different to how it was originally saved. No ReFill or sample names have changed. It's using PinkNoise but this is no way a criticism of them, they're awesome. This is a Reason bug.
You'll note that Search Folder and Search Locations does nothing, while Replace takes 15 seconds just to scan 5 filenames, still can't find them even though you can see them right there, then, it just throws you to a competely different sample folder in another product that you'd browsed to once, several weeks ago.
Aeria gloris, Patrick!
But here's what can happen with NN-19 if the ReFill location is in any way different to how it was originally saved. No ReFill or sample names have changed. It's using PinkNoise but this is no way a criticism of them, they're awesome. This is a Reason bug.
You'll note that Search Folder and Search Locations does nothing, while Replace takes 15 seconds just to scan 5 filenames, still can't find them even though you can see them right there, then, it just throws you to a competely different sample folder in another product that you'd browsed to once, several weeks ago.
Aeria gloris, Patrick!
hello,
isn't it possible to 'self-contain' songs when saving
at which point any samples will be saved into the correct folder
i could be missing something
cheers,
j
isn't it possible to 'self-contain' songs when saving
at which point any samples will be saved into the correct folder
i could be missing something
cheers,
j
littlejamaicastudios
i7 2.8ghz / 24GB ddr3 / Quadro 4000 x 2 / ProFire 610
reason 10 / reaper / acidpro /akai mpk mini / korg padkontrol / axiom 25 / radium 49
'i get by with a lot of help from my friends'
i7 2.8ghz / 24GB ddr3 / Quadro 4000 x 2 / ProFire 610
reason 10 / reaper / acidpro /akai mpk mini / korg padkontrol / axiom 25 / radium 49
'i get by with a lot of help from my friends'
you are doing it the wrong way, I have made a PDF describing how it should be done step by step.
Will share it shortly.
Will share it shortly.
Posted it here as it might be helpful to some ppl.
About a year ago, I organized all of my purchased refills and renamed many of the folders. I would get the message of doom when opening song files that made use of the now moved files. I simply used the window to point to the new location, files found instantly, saved and never had a problem since.
I never renamed any of the refill file names though, so can't speak on that scenario. Only renamed folders and sub folders.
I never renamed any of the refill file names though, so can't speak on that scenario. Only renamed folders and sub folders.
Relax. Listen to some music.
https://soundcloud.com/officialstrangers
https://soundcloud.com/areweghosts
https://officialstrangers.bandcamp.com/releases
https://soundcloud.com/officialstrangers
https://soundcloud.com/areweghosts
https://officialstrangers.bandcamp.com/releases
-
- Posts: 536
- Joined: 03 Aug 2016
I've been following this thread with interest and am wondering how bad the problem really is. I don't have any way of testing it myself right now. Jiggery-Pokery: did you look at bitley's PDF from the other thread that he linked to near the bottom of this one? I'd love to know if that actually does solve the problems you've been demonstrating, or if it's a miscommunication of some kind, solving a different problem altogether, etc. This seems like a troubling issue for anyone who uses a lot of ReFills and I'd like to know what to expect if I ever run into it myself.JiggeryPokery wrote: ↑23 Aug 2018I explained at some depth why it doesn't work, Patrick. So please quit giving people here the Sarah Sanders routine.
Speaking soley from extensive experience in Windows, if the ReFill name gets disassociated from the sample, and is thus missing from the missing sample window—and I've no idea how and when this happens, but I've seen it multiple times—you cannot update your samples on reopening that ancient track with a ReFill of a different product name even if it contains exactly the same samples. And NN-19 sample references won't update at all even if the product name is the same. Which bit of that is unclear?
I changed the name of my first two organ ReFills in 2007 (originally they were "Jiggery-Pokery's Combo Compact" etc, and I dumped the "Jiggery-Pokery's" from the internal name of 1.5. Fortunately no-one bought it before that rerelease as I didnt really advertise it, but it's screwed me a few times reopening my own old tracks of the era. I had to dig around my external hard drives and find the originals: Reason simply would not see the samples in the 1.5 release, which themselves had not changed at all. I'd do a video, but if you watched it you wouldn't then have the decency to acknowledge you're wrong. And sorry to be harsh, but you are.
So 2007 was the last time I changed a product name at info.txt level.
That was in 2007, Patrick. You're still doing it and potentially forcing your users to have multiple versions of the same product in order to reliably open old song files without any hassle. If you've really not had this issue, or don't mind manually reconstructing your patches on opening old songs, that's fine: it's possible others have had no issue and I'm totally happy to accept that. But that's no excuse to entirely dismiss the experiences of people who have had issues by telling them their experience is untrue.
-
- Information
-
Who is online
Users browsing this forum: No registered users and 46 guests