So would something like what others have suggested not be possible, the solution where at least in the places section you could immediately show all files but continue indexing them in the background to show up in the browser and searches? That way you get the best of both worlds, the user doesnt have to turn on/off indexing, but they still get immediate access to any files in their places while still being able to eventually find them in the browser area and searches once they are indexedAmaury wrote:Hi,
To answer a few questions from this thread:
- Offering a 'don't scan this folder' feature is not simple and not a quick fix. The browser is build to display data from a database, only. We can imagine a way to display data from the file system only, but this has to be considered as a feature of its own. Not only is it a technical change that's not too small, but we'd also need to provide clarity in the GUI about what is behaving as a registered folder using features such as fast search, filtering contents in Hot-Swap mode, and what is just showing files on the hard drive, possibly to way to move from one to the other "worlds". It is imaginable, but at this moment we are working on improving indexer performances because that is what may potentially impact all users and will clear the ground for other desires.
- We are working on speeding up the indexer with the goals that files show as fast as possible during an initial scan, and that there is no negative impact on each start of the program while folders are already registered. So far it is known that initial scan takes way too long, and that scanning for changes on each start of Live also takes too long, and may impact playback on OSX. These are the three things we are working on addressing.
Kind regards,
Amaury
Live 9 browser NIGHTMARE !!!
Re: Live 9 browser NIGHTMARE !!!
Re: Live 9 browser NIGHTMARE !!!
Push will only find racks, not samples. That is across the board, not just in places.skatr2 wrote:I did a quick search and push includes samples in its browser. When added to the places section of live, it will access that area to pull out personal samples and racks.
Re: Live 9 browser NIGHTMARE !!!
That's imaginable yes. After we fix the indexer performances, we actually want to look into something of this effect.ezelkow1 wrote:So would something like what others have suggested not be possible, the solution where at least in the places section you could immediately show all files but continue indexing them in the background to show up in the browser and searches? That way you get the best of both worlds, the user doesnt have to turn on/off indexing, but they still get immediate access to any files in their places while still being able to eventually find them in the browser area and searches once they are indexedAmaury wrote:...
Ableton Product Team
Re: Live 9 browser NIGHTMARE !!!
No wrong, I do not use M4l and I could ignore session view for my work as a feature, the indexing is cut in stone.3dot... wrote:session view and m4l say they can...and doDoubleDub wrote: Ableton CANNOT say you have to adapt your way of thinking
Btw. I assume the thing is sufficiently discussed, so I use Live 8 till they come back with a solution.
Re: Live 9 browser NIGHTMARE !!!
Amaury:
We don't need a 'don't scan this folder' feature.
We don't need faster indexing.
We need a general "Switch indexing off" feature.
As long as this isn't acknowledged by Ableton, everything else doesn't make sense.
We don't need a 'don't scan this folder' feature.
We don't need faster indexing.
We need a general "Switch indexing off" feature.
As long as this isn't acknowledged by Ableton, everything else doesn't make sense.
Re: Live 9 browser NIGHTMARE !!!
Right, but as he pointed out, they've 'thrown out the baby with the bathwater' and now the browser depends entirely on the database, rather than keeping the old filesystem based approach as a fallback.beatz01 wrote:Amaury:
We don't need a 'don't scan this folder' feature.
We don't need faster indexing.
We need a general "Switch indexing off" feature.
As long as this isn't acknowledged by Ableton, everything else doesn't make sense.
Depending on the architecture of the indexing system, satisfying our needs may be quite difficult. If the main Live app and the indexer have some form of IPC (inter-process communication) then what they could do is for user places, first do a breadth first folder scan and display those folders. Then keep running the indexer on those folders in whatever order UNLESS the user expands a particular folder. In that case you could then interrupt the indexer to scan the requested folder, updating the browser as its scanned. Then once that folder is complete return back to the previous queue.
That way you get both features, full indexing over time and rapid display of the data the user wants to see.
But if it's the case that Live and the indexer don't talk to each other at all, i.e. one populates the database and the other just displays whats in it, then you've basically got 2 options : 1. optimise the indexer to reduce the latency between adding and displaying content or 2. implement the above scheme but using the database itself as a means of communication, i.e. when you open a folder in the browser, add an entry to the db to say its been requested and have the indexer check for these prioritised entries at some point like with a timer based interrupt, at the end of a folder, after X entries etc..
That's my semi-educated guess at possible strategies.
From the sounds of it they're just focusing on optimising the indexing process itself rather than optimising the interaction between the user, live and the indexing system, but their responses are quite vague and I certainly don't expect them to provide any deep technical insights into what they're doing.
Just have to cross our fingers and hope for the best
-
- Posts: 1715
- Joined: Fri May 27, 2011 8:52 am
- Location: South London
- Contact:
Re: Live 9 browser NIGHTMARE !!!
yepmdk wrote:Right, but as he pointed out, they've 'thrown out the baby with the bathwater' and now the browser depends entirely on the database, rather than keeping the old filesystem based approach as a fallback.beatz01 wrote:Amaury:
We don't need a 'don't scan this folder' feature.
We don't need faster indexing.
We need a general "Switch indexing off" feature.
As long as this isn't acknowledged by Ableton, everything else doesn't make sense.
Depending on the architecture of the indexing system, satisfying our needs may be quite difficult. If the main Live app and the indexer have some form of IPC (inter-process communication) then what they could do is for user places, first do a breadth first folder scan and display those folders. Then keep running the indexer on those folders in whatever order UNLESS the user expands a particular folder. In that case you could then interrupt the indexer to scan the requested folder, updating the browser as its scanned. Then once that folder is complete return back to the previous queue.
That way you get both features, full indexing over time and rapid display of the data the user wants to see.
But if it's the case that Live and the indexer don't talk to each other at all, i.e. one populates the database and the other just displays whats in it, then you've basically got 2 options : 1. optimise the indexer to reduce the latency between adding and displaying content or 2. implement the above scheme but using the database itself as a means of communication, i.e. when you open a folder in the browser, add an entry to the db to say its been requested and have the indexer check for these prioritised entries at some point like with a timer based interrupt, at the end of a folder, after X entries etc..
That's my semi-educated guess at possible strategies.
From the sounds of it they're just focusing on optimising the indexing process itself rather than optimising the interaction between the user, live and the indexing system, but their responses are quite vague and I certainly don't expect them to provide any deep technical insights into what they're doing.
Just have to cross our fingers and hope for the best
seriously fellas - there was enough noise about browser in beta (on this forum as well)
if it was that important to you then you should have taken the trial or got on the beta????
what gives?
-
- Posts: 4478
- Joined: Wed Oct 24, 2007 4:50 am
Re: Live 9 browser NIGHTMARE !!!
i'm surprised that they've managed to screw up the implementation of indexing and database management so badly. it makes it look like the dev team didn't have any search/database experts on board.
Re: Live 9 browser NIGHTMARE !!!
probably too busy designing the browser around a piece of hardware that most of us will never use.fishmonkey wrote:i'm surprised that they've managed to screw up the implementation of indexing and database management so badly. it makes it look like the dev team didn't have any search/database experts on board.
Re: Live 9 browser NIGHTMARE !!!
.
Last edited by beatz01 on Thu Mar 21, 2013 8:16 am, edited 1 time in total.
Re: Live 9 browser NIGHTMARE !!!
This.mdk wrote:
probably too busy designing the browser around a piece of hardware that most of us will never use.
It all seems like L9 was mainly designed with one purpose:
To push the sales of Push.
Or in other words, to have a similar product like Maschine, and to make L9 the Ableton equivalent of the Maschine software no matter what.
Re: Live 9 browser NIGHTMARE !!!
We first are optimizing the indexer performance because that is a pre-requisite, we'll then look at optimizing the interaction between the browser and the indexer somewhat similar to what you describe.mdk wrote:Right, but as he pointed out, they've 'thrown out the baby with the bathwater' and now the browser depends entirely on the database, rather than keeping the old filesystem based approach as a fallback.beatz01 wrote:Amaury:
We don't need a 'don't scan this folder' feature.
We don't need faster indexing.
We need a general "Switch indexing off" feature.
As long as this isn't acknowledged by Ableton, everything else doesn't make sense.
Depending on the architecture of the indexing system, satisfying our needs may be quite difficult. If the main Live app and the indexer have some form of IPC (inter-process communication) then what they could do is for user places, first do a breadth first folder scan and display those folders. Then keep running the indexer on those folders in whatever order UNLESS the user expands a particular folder. In that case you could then interrupt the indexer to scan the requested folder, updating the browser as its scanned. Then once that folder is complete return back to the previous queue.
That way you get both features, full indexing over time and rapid display of the data the user wants to see.
But if it's the case that Live and the indexer don't talk to each other at all, i.e. one populates the database and the other just displays whats in it, then you've basically got 2 options : 1. optimise the indexer to reduce the latency between adding and displaying content or 2. implement the above scheme but using the database itself as a means of communication, i.e. when you open a folder in the browser, add an entry to the db to say its been requested and have the indexer check for these prioritised entries at some point like with a timer based interrupt, at the end of a folder, after X entries etc..
That's my semi-educated guess at possible strategies.
From the sounds of it they're just focusing on optimising the indexing process itself rather than optimising the interaction between the user, live and the indexing system, but their responses are quite vague and I certainly don't expect them to provide any deep technical insights into what they're doing.
Just have to cross our fingers and hope for the best
Kind regards,
Amaury
Ableton Product Team
Re: Live 9 browser NIGHTMARE !!!
So i guess that means to make indexing a (switchable) option is a "no option" for Ableton ?Amaury wrote:We first are optimizing the indexer performance because that is a pre-requisite, we'll then look at optimizing the interaction between the browser and the indexer somewhat similar to what you describe.
Kind regards,
Amaury
Really, a clear straight answer to this question would be much appreciated.
Re: Live 9 browser NIGHTMARE !!!
I'm not really seeing the downside here. Truth is, many of us have been clamoring for something like push for years. A controller does the job but you spend more time getting it to work with Ableton than actually making music. Even the apc didn't meet production needs out the box. We had to wait and hope until someone tore apart the script to make it more functional.beatz01 wrote:This.mdk wrote:
probably too busy designing the browser around a piece of hardware that most of us will never use.
It all seems like L9 was mainly designed with one purpose:
To push the sales of Push.
Or in other words, to have a similar product like Maschine, and to make L9 the Ableton equivalent of the Maschine software no matter what.
Truth is Ableton was losing market share to NI as people started to get into maschine. They needed to compete as NI has a LOT more of a software spread that they are actively integrating. If live wasn't built around some form of central controller, they would have probably sealed their fate. Especially with live-like systems such as bitwig trying to grab up their share of the market. While the hardcore producers may be inconvenienced with their mass of samples they will likely never use, Ableton as a company needs to appeal to the broader populace.
Re: Live 9 browser NIGHTMARE !!!
No indexing at all is not an option. Making scanning more transparent is what we are working on. The browser is driven by the database, and we use the database and queries for many things, such as Hot-Swap filtering or search.beatz01 wrote:So i guess that means to make indexing a (switchable) option is a "no option" for Ableton ?Amaury wrote:We first are optimizing the indexer performance because that is a pre-requisite, we'll then look at optimizing the interaction between the browser and the indexer somewhat similar to what you describe.
Kind regards,
Amaury
Really, a clear straight answer to this question would be much appreciated.
Once the scanning is made more transparent, we'll see what's left of wishes to "browse un-indexed locations" and decide then. We have to do it in this order.
Kind regards,
Amaury
Ableton Product Team