R13 (.1) Browser woes

[joeyluck]

Yeah I have that capability and I do that from time to time, but I also like to see the list to see what is previous and next.

What do you mean “the list”? My suggestion is specifically so you can keep the browser (list?) visible and still grab the filter (or any parameter) while browsing, which I thought was the goal?

The alternative is what we’re trying to avoid (I think), which is closing the Browser so you can find the filter graphic on screen with the mouse so you can then adjust it as you play (which requires you to keep the filter knob in view). At which point you can no longer see “the list”, correct?

Thinking I might be confused about this, I tested it with my Novation SL MkIII and it works flawlessly, and there are already knobs assigned to the filter (and many more) so I don’t even need to create anything - just use the up/down arrows to browse while seeing the full list, and tweak away as you play - which all seem to be such a better way to implement this workflow than any alternatives IMO regardless of screen size (even if the browser wasn’t an issue this approach would still make more sense to me).

Or have I misunderstood something important here?

Oh I misread what you were saying and was thinking about mapping the patch next and previous buttons. But no, I don't have a controller assigned to every control of every device, not to mention that not every control is Remotable, nor am I looking to figure out which control is which for every device while not seeing the device. The Filter is just one of many examples. I use a laptop and I'm often on the go and rarely have controllers with me aside from small things like my Seaboard Block.

This workflow was not an issue in previous versions, so not looking for a brand new solution that requires a lot of thinking—it just involves an option of making the Browser smaller width-wise and/or dockable and that would solve many issues. The Browser in previous versions can actually be made smaller than the Device Palette (approximately 12% smaller that that). The Browser width now at its smallest is nearly 4x the width of the Browser at its smallest before. That is a world of difference, especially on a laptop.

[joeyluck]

One suggestion is a compact mode for the Browser, which could be made the same size as the Device Palette. Just a little button in the upper corner to switch view modes.

Then even if we don't get a dockable Browser option, you could fake it by leaving the Device Palette open and moving the Browser over top of it...

Compact Browser.gif (810.17 KiB) Viewed 3298 times

And you wouldn't have to place it there. I think a compact Browser, even if not dockable, would be acceptable anywhere on most anybody's screen.

[Loque]

One suggestion is a compact mode for the Browser, which could be made the same size as the Device Palette. Just a little button in the upper corner to switch view modes.

Then even if we don't get a dockable Browser option, you could fake it by leaving the Device Palette open and moving the Browser over top of it...


Compact Browser.gif


And you wouldn't have to place it there. I think a compact Browser, even if not dockable, would be acceptable anywhere on most anybody's screen.

Yea, good idea. Especially if filtering is done and I only browse for patches...

[joeyluck]

One suggestion is a compact mode for the Browser, which could be made the same size as the Device Palette. Just a little button in the upper corner to switch view modes.

Then even if we don't get a dockable Browser option, you could fake it by leaving the Device Palette open and moving the Browser over top of it...


Compact Browser.gif


And you wouldn't have to place it there. I think a compact Browser, even if not dockable, would be acceptable anywhere on most anybody's screen.

Yea, good idea. Especially if filtering is done and I only browse for patches...

Yeah that's the way I see it. If I decide I want to search for something using tags, and go on a deep dive, I'd use the Browser in its larger view. If I've navigated to a folder and then just want to start scrolling through patches, I'd be much happier with the compact view.

And this is just one suggestion. I'd also be happy even if the Browser could just be made half of the width of its current smallest size. Any adjustment would help.

[Loque]

Yea, good idea. Especially if filtering is done and I only browse for patches...

Yeah that's the way I see it. If I decide I want to search for something using tags, and go on a deep dive, I'd use the Browser in its larger view. If I've navigated to a folder and then just want to start scrolling through patches, I'd be much happier with the compact view.

And this is just one suggestion. I'd also be happy even if the Browser could just be made half of the width of its current smallest size. Any adjustment would help.

[Whoopdee]

I tried to give R13 another chance...

Nope, the changes kill my workflow. The monochrome icons and UI of the browser kill me.

[WOO]

I am about to uninstall 13, because i can't use it. Everything about it is much slower than 12 or 11. Whether opening up 13 or loading up a small project in 13 . It takes 3- 5 minutes. And then once a project loads up it stutters and glitches regardless of what the latency settings are. So when that happens if i open the browser it shows all folders spinning wheel spinning and until that stops I have trouble with playback. I've gone into control panel in windows to see if their is some process running that's using up resources but nothing but reason shoes up. Still have 12 and 11 installed and they still work as expected. Can't understand why the indexing is still running . I installed reason last week and i leave it on for hours at a time. Indexing should be complete by now. It took 3 days before my packs folder showed up in the browser. I have about a 100 gigs of refills and some midi, loops and wave files spread out in different folders located on my desktop and whatever else came with 11 12 and now 13. Is there something i need to do from an organizational standpoint with my collection of loops, midi files and waves to make it quicker and easier for reason to index? Would be most grateful for any advice. Btw when i close out of reason if i go into task manager it still shows reason as a running process. Noticed that same behavior when closed out of 12 even before installing 13. When i use 11 and haven't opened up 12 or 13 when i close out of it, the reason process no longer shows up in task manager. Is that normal, the process still showing up after closing out 12 and 13?

[dvdrtldg]

Whether opening up 13 or loading up a small project in 13 . It takes 3- 5 minutes.

Yeah this is annoying. I'm not having any major problems browsing or loading sessions, but I do get sick of the long wait time when launching 13 from scratch. Four minutes is about the average for me, I have to try to remember never to close the application

Also, I like to run the sample rate at 48K but if I close and re-open 13, it's always defaulted back to 44.1, which is obviously a bug...?

[mind2069]

I tried to give R13 another chance...

Nope, the changes kill my workflow. The monochrome icons and UI of the browser kill me.

I hate the monochrome with a passion too.

The sad thing it's not coming back, they've been going more and more monochrome with each release

But the workflow is more important, I was going to give it a shot after the last update but the post after yours about the performances worries me

Does anyone else experience less performance than Reason 12?

[bieh]

it is objectively better in every way imaginable ‍♂️

A virtually complete inability to find or load some patches is not "objectively better", obviously. Having said that, based on your comments so far, I'm definitely not holding my breath expecting that you'll stop being dismissive of other people's genuine concerns.

[bieh]

Any other gripe that needs squashing?

Yes - the ones you've ignored so far because they don't fit your dismissive narrative of "everything's better".

[mind2069]

Whether opening up 13 or loading up a small project in 13 . It takes 3- 5 minutes.

Yeah this is annoying. I'm not having any major problems browsing or loading sessions, but I do get sick of the long wait time when launching 13 from scratch. Four minutes is about the average for me, I have to try to remember never to close the application

Also, I like to run the sample rate at 48K but if I close and re-open 13, it's always defaulted back to 44.1, which is obviously a bug...?

Your saying loading a blank/empty Reason 13 is 4 minutes?

I have long loading times with Reason 12 (3 minutes) but those are "large" projects with hundreds of devices or vsts, so I consider it normal, will I wait 15 minutes for large Reason 13 projects?

I just tested 12 blank/empty and it's like 8 seconds, are the performances of 13 that bad, forget it I will wait for the next update.

[PhillipOrdonez]

it is objectively better in every way imaginable ‍♂️

A virtually complete inability to find or load some patches is not "objectively better", obviously. Having said that, based on your comments so far, I'm definitely not holding my breath expecting that you'll stop being dismissive of other people's genuine concerns.

Fine, I hope RS addresses the bug filings you’ve totally created right?

[bieh]

Fine, I hope RS addresses the bug filings you’ve totally created right?

Yes, I've "totally" created a bug report.

[PhillipOrdonez]

Fine, I hope RS addresses the bug filings you’ve totally created right?

Yes, I've "totally" created a bug report.

Awesome! 🥳

[bieh]

Your saying loading a blank/empty Reason 13 is 4 minutes?

For another perspective, my mostly up-to-date PC (new as of March 2024) with a large number of REs and VSTs takes 1 minute and 20 seconds to open Reason 13. Once it's open, a project in progress with 16 audio tracks and 13 MIDI tracks takes 1 minute and 47 seconds to open. If instead, I open Reason by directly opening the same project file while Reason is closed, it takes 2 minutes before the project is ready to use.

On the same computer, Reason 12 takes 20 seconds to open. Once it's open, a nearly finished project with 2 audio tracks, 23 instrument tracks, 13 automation tracks, 26 mixer channels and 43 devices overall (REs & VSTs), takes 1 minute and 44 seconds to load.

Cubase 13 with all the same VSTs plus Cubase stock devices that aren't standard VSTs (and obviously minus the REs except as accessed through the Reason Rack device) - fewer devices to load overall - takes 26 seconds to open. After that, an orchestral project with 33 orchestral instruments takes 14 seconds to open. A 20-second sound design project with 62 audio tracks takes 32 seconds to open.

[Loque]

Your saying loading a blank/empty Reason 13 is 4 minutes?

For another perspective, my mostly up-to-date PC (new as of March 2024) with a large number of REs and VSTs takes 1 minute and 20 seconds to open Reason 13. Once it's open, a project in progress with 16 audio tracks and 13 MIDI tracks takes 1 minute and 47 seconds to open. If instead, I open Reason by directly opening the same project file while Reason is closed, it takes 2 minutes before the project is ready to use.

On the same computer, Reason 12 takes 20 seconds to open. Once it's open, a nearly finished project with 2 audio tracks, 23 instrument tracks, 13 automation tracks, 26 mixer channels and 43 devices overall (REs & VSTs), takes 1 minute and 44 seconds to load.

Cubase 13 with all the same VSTs plus Cubase stock devices that aren't standard VSTs (and obviously minus the REs except as accessed through the Reason Rack device) - fewer devices to load overall - takes 26 seconds to open. After that, an orchestral project with 33 orchestral instruments takes 14 seconds to open. A 20-second sound design project with 62 audio tracks takes 32 seconds to open.

I guess some of your cache files are corrupt... Still worth to create a ticket, since it is not normal...

[WOO]

I guess some of your cache files are corrupt... Still worth to create a ticket, since it is not normal...

Will uninstalling and reinstalling 13 solve that?

[Arrant]

I was supposed to be having some quality music making time right now but instead I'm frustrated by the browser and coming on here to complain about it
In this case I used the Reason rack plugin in Studio one and wanted to drop some Mimic in there. So I insert RRP, add a Mimic and from there I want to browse for samples.However I'm met by a blank browser. Click on "All locations", and stuff from the factory bank shows up after a short delay. Click on any of my shortcuts and the browser is blank again. So my "All locations" has the Reason stock stuff in it, but none of my shortcuts to folders work. The only way I can get to my user sample libary is to go all the way via "This PC" or "Desktop" and navigate folder by folder. I'll file a bug report I guess.

EDIT: This resolves after a finished scan, which took around an hour. I guess this is some sort of incremental scan, as the full original scan took much longer.
Obviously I can't live with an hour wait time, so the bug report is still valid.

On another note, what do people get out of coming on here and being dismissive of other users' problems just because something is working for you?
It's not like those problems don't exist. I have massive problems with the new browser and so do plenty of other people.

[PhillipOrdonez]

On another note, what do people get out of coming on here and being dismissive of other users' problems just because something is working for you?
It's not like those problems don't exist. I have massive problems with the new browser and so do plenty of other people.

I guess you’re talking about me. See, I had these issues happen to me back in the early stages of 13, and it sucked to have an empty browser, and have to wait for the indexing to complete. So I get it. But it has been fixed and if it’s an issue for you still, report the bug away so support can help you.

However there seems to be a conflation between two very different aspects. It’s one thing that the browser isn’t working as intended in your machine right now vs the browser being worse than it was because it isn’t docked or some reason that stems out of not knowing how to use it properly. It is objectively miles better in every way. It destroys the old browser in usability and functionality once it gelled with your machine and does the indexing properly.

There’s no secret about my feelings towards the new browser, and I know most if not everyone will come to like it once they get used to it and will look back at the old browser as a clunky, slow thing. You (not you specifically, arrant) just need to give it a chance and let go

[selig]

Oh I misread what you were saying and was thinking about mapping the patch next and previous buttons. But no, I don't have a controller assigned to every control of every device, not to mention that not every control is Remotable, nor am I looking to figure out which control is which for every device while not seeing the device. The Filter is just one of many examples. I use a laptop and I'm often on the go and rarely have controllers with me aside from small things like my Seaboard Block.

This workflow was not an issue in previous versions, so not looking for a brand new solution that requires a lot of thinking—it just involves an option of making the Browser smaller width-wise and/or dockable and that would solve many issues. The Browser in previous versions can actually be made smaller than the Device Palette (approximately 12% smaller that that). The Browser width now at its smallest is nearly 4x the width of the Browser at its smallest before. That is a world of difference, especially on a laptop.

Seems like a tiny difference in workflows, the only difference being you would NOW have to close the browser before tweaking all the different parameters, then open it again to move to the next patch, close the browser and back to tweaking (two extra steps). Shame about your controller not having presets for Reason devices like others…

I REALLY have to wonder why we need TWO different browsers in the first place, and why they don’t at LEAST have more consistent behavior between the two (consistency across the interface has never been a Reason strong point).
Why not just one Browser, and let it be dock-able or floating, your choice. Oh well, that’s not gonna happen any time soon now…

[selig]

On another note, what do people get out of coming on here and being dismissive of other users' problems just because something is working for you?
It's not like those problems don't exist. I have massive problems with the new browser and so do plenty of other people.

I just reviewed the thread and didn’t find anyone dismissing your issues. Some folks here are questioning other issues and providing possible workarounds. One guy thinks the new browser is fantastic (despite removing device favorites from the device browser), but wasn’t responding to your specific issues (many folks are talking among themselves in this thread rather than talking to you directly).

I can’t speak for others, but if I’m complaining about something I like to know if it’s just me or if others are having the same issue (and how many others vs those not having the issue). I find it helpful, but I could see how it might come across as suggesting you are crazy (imagining things) for having a problem someone else doesn’t have.

However, the number of times folks come and complain about something, only to have someone else point out what they are doing wrong, is a non zero number. Which is helpful because it is a solution to the problem, which is the goal right?

[chimp_spanner]

I was supposed to be having some quality music making time right now but instead I'm frustrated by the browser and coming on here to complain about it
In this case I used the Reason rack plugin in Studio one and wanted to drop some Mimic in there. So I insert RRP, add a Mimic and from there I want to browse for samples.However I'm met by a blank browser. Click on "All locations", and stuff from the factory bank shows up after a short delay. Click on any of my shortcuts and the browser is blank again. So my "All locations" has the Reason stock stuff in it, but none of my shortcuts to folders work. The only way I can get to my user sample libary is to go all the way via "This PC" or "Desktop" and navigate folder by folder. I'll file a bug report I guess.

EDIT: This resolves after a finished scan, which took around an hour. I guess this is some sort of incremental scan, as the full original scan took much longer.
Obviously I can't live with an hour wait time, so the bug report is still valid.

On another note, what do people get out of coming on here and being dismissive of other users' problems just because something is working for you?
It's not like those problems don't exist. I have massive problems with the new browser and so do plenty of other people.

Yeah that sounds super borked!! Where do you keep your samples, out of interest? And are you adding the entire drive as a location or individual folders? I imagine there are SO many variables that determine what kind of experience users are having. Me, I just have a single internal 8TB drive and I point to folders on it. Others might be using USB mechanical drives, or SSDs (which are certainly not created equal), or NVME, or PCIe. I'd hope that with enough user reports they'll focus in on the problem! But sucks you've been having a rough time, and I hope you get a helpful response soon.

[chimp_spanner]

Oh I misread what you were saying and was thinking about mapping the patch next and previous buttons. But no, I don't have a controller assigned to every control of every device, not to mention that not every control is Remotable, nor am I looking to figure out which control is which for every device while not seeing the device. The Filter is just one of many examples. I use a laptop and I'm often on the go and rarely have controllers with me aside from small things like my Seaboard Block.

This workflow was not an issue in previous versions, so not looking for a brand new solution that requires a lot of thinking—it just involves an option of making the Browser smaller width-wise and/or dockable and that would solve many issues. The Browser in previous versions can actually be made smaller than the Device Palette (approximately 12% smaller that that). The Browser width now at its smallest is nearly 4x the width of the Browser at its smallest before. That is a world of difference, especially on a laptop.

Seems like a tiny difference in workflows, the only difference being you would NOW have to close the browser before tweaking all the different parameters, then open it again to move to the next patch, close the browser and back to tweaking (two extra steps). Shame about your controller not having presets for Reason devices like others…

I REALLY have to wonder why we need TWO different browsers in the first place, and why they don’t at LEAST have more consistent behavior between the two (consistency across the interface has never been a Reason strong point).
Why not just one Browser, and let it be dock-able or floating, your choice. Oh well, that’s not gonna happen any time soon now…

The only instance in which I've found two browsers to be useful is when I'm sample digging, and I find something that I like, I can then conduct a separate, second search for a sample based instrument and drag that in without disrupting my sample search. I suppose this could be replicated from a single browser though if it just had a 'back' button, or separate tabs for devices and presets/samples with their own states.

[Arrant]

On another note, what do people get out of coming on here and being dismissive of other users' problems just because something is working for you?
It's not like those problems don't exist. I have massive problems with the new browser and so do plenty of other people.

I guess you’re talking about me. See, I had these issues happen to me back in the early stages of 13, and it sucked to have an empty browser, and have to wait for the indexing to complete. So I get it. But it has been fixed and if it’s an issue for you still, report the bug away so support can help you.

However there seems to be a conflation between two very different aspects. It’s one thing that the browser isn’t working as intended in your machine right now vs the browser being worse than it was because it isn’t docked or some reason that stems out of not knowing how to use it properly. It is objectively miles better in every way. It destroys the old browser in usability and functionality once it gelled with your machine and does the indexing properly.

There’s no secret about my feelings towards the new browser, and I know most if not everyone will come to like it once they get used to it and will look back at the old browser as a clunky, slow thing. You (not you specifically, arrant) just need to give it a chance and let go

I'm also talking about a post by a certain sound designer which was then wisely deleted.
Agree 100% with you about separating errors from design/workflow preferences. I see where RS wants to go with the new browser and would happily use if it worked as advertised, even though I'm not a fan of the UI or indeed the workflow. When errors stop me repeatedly from doing basic tasks, it's not good enough and I've filed a bug report. However, calling it (or anything really) "objectively" better is asking for a heated discussion IMO, not that I'll bite though

Glad to hear that the new browser is working well for you now, maybe there's hope for us all.