Propellerhead should improve search performance of folders containing Refills and other audio files.
One of the main things, that in my opinion is long due (and should have been tackled with version 8, since they are revising the workflow) is to improve the search performance of RFL content and other audio files.
Propellerhead should ask the user which folders contain the sound collection and index all the content of rfls, and other audio files specified by the user. This should make the search much faster.
Propellerhead should ask the user which folders contain the sound collection and index all the content of rfls, and other audio files specified by the user. This should make the search much faster.
- Puckboy2000
- Posts: 265
- Joined: 22 Mar 2015
- Location: SoCal
I agree. I keep making samples and forgetting where I put them. I wish it would search the whole computer for the files and refills. Although maybe the new drop menu does that? I couldn't tell from the video I watched and I haven't upgraded yet.
"Think of how stupid the average person is, and realize half of them are stupider than than that" - George Carlin
- CharlyCharlzz
- Posts: 906
- Joined: 15 Jan 2015
if they do this you will loose the detection of new refill's into the index and have to throw a full scan to add it in the list IMO .
Windows know a new refill is in the folder so maybe they could work something .....maybe
but I dont find it slow and I am on 7.1 so I Wonder what are your computer specs ?
It does not die , it multiplies !
7.101 and I will upgrade maybe this summer .
7.101 and I will upgrade maybe this summer .
Puckboy2000, it can search a whole drive, but that will take ages with the currently implemented search.
CharlyCharlzz, I think that if the system detects and only scan the changes of the directory, it will be quite efficient. I am pretty sure that Propellerhead will nail it if they do it, the only question is when :s. Other DAWs such as Ableton, do index their sounds, so I think they can as well.
CharlyCharlzz, I think that if the system detects and only scan the changes of the directory, it will be quite efficient. I am pretty sure that Propellerhead will nail it if they do it, the only question is when :s. Other DAWs such as Ableton, do index their sounds, so I think they can as well.
CharlyCharlzz, forgot to add that the laptop I use is quite up to spec (i7 3.0 ghz 8gb Ram), so it is not what is causing it. Search performance degrades when you search in a folder with several gigs of samples, and with 1000's of patches.
- CharlyCharlzz
- Posts: 906
- Joined: 15 Jan 2015
@nscerri yhea I like virtusal dj 8 browser for exemple that integrate i-tune covers or just instent search but I have around the same specs you have on my laptop and a big refill folder but there is only refill's and patch's in it , for samples you enter a slow zone so I have a sample folder with all my wav's in it .
I think props really have a fast browser and I am on 7.1 but a fast refill browser not sample broser , got a nice refill Library File and no sub folder's other then the patch's one , all the refill's are in it uncompressed so maybe this is why I got a faster brosing time , also my favorites in reason browser have this folder selected wich just take one click and 4sc's to open and access all my refill's but I cut down my Library to around (30 go) because refill is a compressed format so this is already huge but even when I had 80 go 's most of it was all the wav's and samples that I had already in refill format but I just throwed the all 3 CD's of sound in my Refill folder when only one of the cd's was a refill wich was slowing everything up .
I think it's fast enougth for a refill's Library but I have not tryed to open my 145 GO akai wav Library for a long time with reason
It does not die , it multiplies !
7.101 and I will upgrade maybe this summer .
7.101 and I will upgrade maybe this summer .
@prndrsn My laptop hard disk is mechanical and spins @ 5400rpm (it is in my plans to upgrade to SSD, as this surely affects loading of samples). It would still make a difference if Propellerhead indexes the sound library even if you have an SSD as it will not have to search for all files each time you hit the search. Having said that, I compared the search with the one of Ableton using the same laptop, the difference is enormous.
@CharlyCharlzz Browsing in Reason is much better now with 8, and I also feel that my workflow has improved a lot. It is easier to assign samples/patches using drag and drop, and after the update with the revert feature, they solved one of the big issues I had. My problem is not with the browser, but with the search, which definitely needs more work. One thing that I am doing is picking up wav file samples and converting them to rfl, as as you are stating, the loss less compression algorithm they use is impressive and also noticed that the search runs faster (but not fast enough )
Thanks
@CharlyCharlzz Browsing in Reason is much better now with 8, and I also feel that my workflow has improved a lot. It is easier to assign samples/patches using drag and drop, and after the update with the revert feature, they solved one of the big issues I had. My problem is not with the browser, but with the search, which definitely needs more work. One thing that I am doing is picking up wav file samples and converting them to rfl, as as you are stating, the loss less compression algorithm they use is impressive and also noticed that the search runs faster (but not fast enough )
Thanks
Bullshit!prndrsn wrote:Search speeds will probably be affected by disk read speeds more than anything. What kind of drive do you have (SSD or mechanical), and what's the RPM of the drive if it's mechanical?
Search speeds will probably be affected by THE PROPELLERHEAD SOFTWARE CODE more than anything.
The Browser in R8 is still slow!
I have tested many computers, operating systems and drives. Over a number of years. Reason is the only DAW that does work very slow with my (wav) database.
FL Studio = fast as hell
Cubase 6 = fast as hell
Ableton Live 8 = fast as hell
Reason 6/7/8 = damn slow
- esselfortium
- Posts: 1456
- Joined: 15 Jan 2015
- Contact:
Yeah, it's surprising that Reason still can't index ReFills and patch/sample folders into a database so it could just do one of these to pull up results in a fraction of a second:
SELECT * FROM v_UserData WHERE File_Type = 'wav' AND File_Name LIKE '%@UserSearchString%' ORDER BY DateAccessed desc
SELECT * FROM v_UserData WHERE File_Type = 'wav' AND File_Name LIKE '%@UserSearchString%' ORDER BY DateAccessed desc
Sarah Mancuso
My music: Future Human
My music: Future Human
- EnochLight
- Moderator
- Posts: 8431
- Joined: 17 Jan 2015
- Location: Imladris
prndrsn wrote:Search speeds will probably be affected by disk read speeds more than anything. What kind of drive do you have (SSD or mechanical), and what's the RPM of the drive if it's mechanical?
While I agree that search could be massively improved in Reason still, it's not bullshit - at all - that disk read speed can affect search speed. @devilfish: if you've tested many computers and drives you should know this. An SSD usually searches much faster than a mechanical hard drive, even with an OS search index feature enabled.devilfish wrote:
Bullshit!
Search speeds will probably be affected by THE PROPELLERHEAD SOFTWARE CODE more than anything.
The Browser in R8 is still slow!
I have tested many computers, operating systems and drives. Over a number of years. Reason is the only DAW that does work very slow with my (wav) database.
FL Studio = fast as hell
Cubase 6 = fast as hell
Ableton Live 8 = fast as hell
Reason 6/7/8 = damn slow
Still, let it be known for the record that I agree search needs to be improved! There needs to be an instant indexing feature, akin to "Google Search", to make it modern.
Win 10 | Ableton Live 11 Suite | Reason 12 | i7 3770k @ 3.5 Ghz | 16 GB RAM | RME Babyface Pro | Akai MPC Live 2 & Akai Force | Roland System 8, MX1, TB3 | Dreadbox Typhon | Korg Minilogue XD
I too agree search times could be improved, but I don't use it very often TBH. What I COULD use is search TAGS. I don't search by name since I don't always know the name of what I'm looking for. Yesterday I was searching for a long deep kick with a snappy attack, yet there are no search terms that would bring all those up and so searching was useless for me (even if it had been lightening fast!).
Sure, tags wouldn't work for non-tagged content like older ReFills, but I sure wish they had started adding tags to the FSB content back when I was a part of developing new patches (R6.5 I believe?) because if they had, then by now things would be rolling along quite nicely IMO.
Sure, tags wouldn't work for non-tagged content like older ReFills, but I sure wish they had started adding tags to the FSB content back when I was a part of developing new patches (R6.5 I believe?) because if they had, then by now things would be rolling along quite nicely IMO.
Selig Audio, LLC
selig wrote:I too agree search times could be improved, but I don't use it very often TBH. What I COULD use is search TAGS. I don't search by name since I don't always know the name of what I'm looking for. Yesterday I was searching for a long deep kick with a snappy attack, yet there are no search terms that would bring all those up and so searching was useless for me (even if it had been lightening fast!).
Sure, tags wouldn't work for non-tagged content like older ReFills, but I sure wish they had started adding tags to the FSB content back when I was a part of developing new patches (R6.5 I believe?) because if they had, then by now things would be rolling along quite nicely IMO.
I wish they add a tagging system that would enable users to add tags to their refills/patches/samples even in the case of old refills. Perhaps, Reason should be able to repack old Refills in the new format to make them tagable.
Also it would be good if one could finally save self containing patches of sample based devices on demand and to be able to save patches in assisting Refills.
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.
selig wrote:I too agree search times could be improved, but I don't use it very often TBH. What I COULD use is search TAGS. I don't search by name since I don't always know the name of what I'm looking for. Yesterday I was searching for a long deep kick with a snappy attack, yet there are no search terms that would bring all those up and so searching was useless for me (even if it had been lightening fast!).
Sure, tags wouldn't work for non-tagged content like older ReFills, but I sure wish they had started adding tags to the FSB content back when I was a part of developing new patches (R6.5 I believe?) because if they had, then by now things would be rolling along quite nicely IMO.
One of the biggest current issues with searching is the fact you can't search EVERYTHING in one search. This is because there's no unified catalog (which undercurrent circumstances is likely a good thing, seeing as how long searching already takes for some folks). But again, I'm rarely searching by name anyway…tiker01 wrote: I wish they add a tagging system that would enable users to add tags to their refills/patches/samples even in the case of old refills. Perhaps, Reason should be able to repack old Refills in the new format to make them tagable. Also it would be good if one could finally save self containing patches of sample based devices on demand and to be able to save patches in assisting Refills.
Selig Audio, LLC
- Exowildebeest
- Posts: 1553
- Joined: 16 Jan 2015
I just use my brain and senses to search, because that's faster.
- TheGodOfRainbows
- Posts: 640
- Joined: 31 Mar 2015
Sure, tags wouldn't work for non-tagged content like older ReFills, but I sure wish they had started adding tags to the FSB content back when I was a part of developing new patches (R6.5 I believe?) because if they had, then by now things would be rolling along quite nicely IMO.selig wrote:I too agree search times could be improved, but I don't use it very often TBH. What I COULD use is search TAGS. I don't search by name since I don't always know the name of what I'm looking for. Yesterday I was searching for a long deep kick with a snappy attack, yet there are no search terms that would bring all those up and so searching was useless for me (even if it had been lightening fast!).
Selig, since you have a working relationship with Propellerhead, have you discussed the possibility of tags with them, or at least mentioned it to them? Anything to improve search is welcome. Do you know how hard it would be to implement such a feature? I know nothing about programming, but it doesn't seem like it would be a particularly difficult thing to do.
@Selig, although I like the idea of tagging, the majority of samples are well named/organised and search results are normally on target. Tagging will improve performance but not as much as indexing names and directories. A hybrid option would be even better
@Exowildebeest, that is what I try to do, but I have too much samples to handle
@Exowildebeest, that is what I try to do, but I have too much samples to handle
The search speed of reason is inexcusable slow. Other applications even without the use of indexing are performing their search at a fraction of the time it takes reason.
Search "algorithms" are so simple they're not even worth calling algorithms, it's just traversing a simple ordered structure.
Just to test it out myself i wrote a simple search and it performed just as fast as the other programs.
Maybe reason is choosing to perform some superfluous operation related to some other functionality the program uses that isn't necessary for search, but one thing is certain, it is needlessly slow.
Search "algorithms" are so simple they're not even worth calling algorithms, it's just traversing a simple ordered structure.
Just to test it out myself i wrote a simple search and it performed just as fast as the other programs.
Maybe reason is choosing to perform some superfluous operation related to some other functionality the program uses that isn't necessary for search, but one thing is certain, it is needlessly slow.
@Avasopht, I tend to disagree with you, you cannot beat a well indexed search with a normal traverse search, whatever the search algorithm that you use. To add to the complexity, rfl files are similar to zip files, so you need to go deeper in the search.
Having said that at least we all agree that currently it is slow
Having said that at least we all agree that currently it is slow
What I'm saying is that the code i wrote uses standard methods and is much faster than reasons search so they are clearly doing something unnecessary.nscerri wrote:@Avasopht, I tend to disagree with you, you cannot beat a well indexed search with a normal traverse search, whatever the search algorithm that you use. To add to the complexity, rfl files are similar to zip files, so you need to go deeper in the search.
Having said that at least we all agree that currently it is slow
searching a refill package works kind of different compared to searching for files on a file allocation table. Refills are a compressed format, while a "normal" file allocation table is not (please note I am using the word "normal" here). So a standard file search method will not work properly since it will mismatch everything located in the refill packages.avasopht wrote:What I'm saying is that the code i wrote uses standard methods and is much faster than reasons search so they are clearly doing something unnecessary.
However, I do agree that refills should be cached in some form, since this will make searching (for the first time) a lot faster if the content is stored in a local cache db if you will.
hydlide wrote:
avasopht wrote:What I'm saying is that the code i wrote uses standard methods and is much faster than reasons search so they are clearly doing something unnecessary.
Well I was addressing the file searching speed. Searching within Refills is significantly faster so I've not really paid attention to it.hydlide wrote:
searching a refill package works kind of different compared to searching for files on a file allocation table. Refills are a compressed format, while a "normal" file allocation table is not (please note I am using the word "normal" here). So a standard file search method will not work properly since it will mismatch everything located in the refill packages.
However, I do agree that refills should be cached in some form, since this will make searching (for the first time) a lot faster if the content is stored in a local cache db if you will.
Compressed or not Propellerhead are free to include data inside to speed up searches, though I always felt they had already.
- tobypearce
- Posts: 576
- Joined: 28 Sep 2015
- Contact:
I'd like to bump this.
I've recently discovered Samplism - it's pretty fantastic, and because it indexes files searching is instant.
When searching for a missing sample, it's quicker to open samplism, search and find the file, drag the folder into Reason's browser, and search from there than it is to search natively within Reason.
On a Mac, Spotlight also indexes, so this route is quicker too.
All of this is painful because Reason is the only program that can search within Refills, or within it's own sound banks, and this takes aaggggeeeesssss.
I've recently discovered Samplism - it's pretty fantastic, and because it indexes files searching is instant.
When searching for a missing sample, it's quicker to open samplism, search and find the file, drag the folder into Reason's browser, and search from there than it is to search natively within Reason.
On a Mac, Spotlight also indexes, so this route is quicker too.
All of this is painful because Reason is the only program that can search within Refills, or within it's own sound banks, and this takes aaggggeeeesssss.
https://onetrackperweek.com
One year - 52 tracks - Electronic Dance Music
One year - 52 tracks - Electronic Dance Music
-
- Information
-
Who is online
Users browsing this forum: No registered users and 2 guests