Propellerhead should improve search performance of folders containing Refills and other audio files.

Have any feature requests? No promise they'll get to Reason Studios, but you can still discuss them here.
User avatar
nscerri
Posts: 116
Joined: 01 Apr 2015
Location: Malta

02 Apr 2015

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.

User avatar
Puckboy2000
Posts: 265
Joined: 22 Mar 2015
Location: SoCal

02 Apr 2015

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

User avatar
CharlyCharlzz
Posts: 906
Joined: 15 Jan 2015

02 Apr 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 .

User avatar
nscerri
Posts: 116
Joined: 01 Apr 2015
Location: Malta

02 Apr 2015

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.

User avatar
nscerri
Posts: 116
Joined: 01 Apr 2015
Location: Malta

02 Apr 2015

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.

prndrsn
Posts: 13
Joined: 03 Apr 2015

03 Apr 2015

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?

I need to check how fast my search is, I haven't thought about it.


User avatar
CharlyCharlzz
Posts: 906
Joined: 15 Jan 2015

03 Apr 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 .

User avatar
nscerri
Posts: 116
Joined: 01 Apr 2015
Location: Malta

03 Apr 2015

@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 :)

User avatar
devilfish
Posts: 183
Joined: 20 Jan 2015

14 Apr 2015

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?
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




User avatar
esselfortium
Posts: 1456
Joined: 15 Jan 2015
Contact:

14 Apr 2015

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
Sarah Mancuso
My music: Future Human

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

14 Apr 2015

Most OSs have filesystem databases these days (e.g. Spotlight on OSX). They just need to make plugins for these systems so they can work with the refills contents..

User avatar
EnochLight
Moderator
Posts: 8405
Joined: 17 Jan 2015
Location: Imladris

14 Apr 2015

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?
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
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.

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

User avatar
selig
RE Developer
Posts: 11685
Joined: 15 Jan 2015
Location: The NorthWoods, CT, USA

14 Apr 2015

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. :)
Selig Audio, LLC

User avatar
tiker01
Moderator
Posts: 1423
Joined: 16 Jan 2015

14 Apr 2015

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.
:rt: :reason: :essentials: :re: :refill: :PUF_balance: :ignition: :PUF_figure:

User avatar
selig
RE Developer
Posts: 11685
Joined: 15 Jan 2015
Location: The NorthWoods, CT, USA

14 Apr 2015

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. :)
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.
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… :)
Selig Audio, LLC

User avatar
Exowildebeest
Posts: 1553
Joined: 16 Jan 2015

14 Apr 2015

I just use my brain and senses to search, because that's faster.

User avatar
TheGodOfRainbows
Posts: 640
Joined: 31 Mar 2015

20 Apr 2015

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. :)

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.

User avatar
nscerri
Posts: 116
Joined: 01 Apr 2015
Location: Malta

10 May 2015

@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  ;)

avasopht
Competition Winner
Posts: 3932
Joined: 16 Jan 2015

10 May 2015

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.

User avatar
nscerri
Posts: 116
Joined: 01 Apr 2015
Location: Malta

10 May 2015

@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 :)

avasopht
Competition Winner
Posts: 3932
Joined: 16 Jan 2015

10 May 2015

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 :)
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.

hydlide

10 May 2015

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.
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.



avasopht
Competition Winner
Posts: 3932
Joined: 16 Jan 2015

10 May 2015

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.
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.

Well I was addressing the file searching speed. Searching within Refills is significantly faster so I've not really paid attention to it.

Compressed or not Propellerhead are free to include data inside to speed up searches, though I always felt they had already.

User avatar
tobypearce
Posts: 576
Joined: 28 Sep 2015
Contact:

30 Jun 2018

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.
https://onetrackperweek.com
One year - 52 tracks - Electronic Dance Music

songsmite
Posts: 24
Joined: 06 Dec 2017

03 Jul 2018

They need to add a database feature for samples and patches.

Post Reply
  • Information
  • Who is online

    Users browsing this forum: No registered users and 7 guests