MPA

I think we are approaching the time to start integrating the new API into the desktop app.
However, before moving forward with that it would be good to discuss the process.

I have a few questions regarding the integration:

1. API completeness:
When implementing the website, we are always finding out that the API is missing functionalities, do you think to be able to review the current state and decide if the API is complete enough to be integrated in the app?
I guess you would also need the have the full scope of features we are planning, for this you could maybe ask me some questions, if i have time i will try to put together a summary of all new features which should be included in the new API.

2. Use of new and old API:
When we start using the new API, will it be still possible to have certain functionalities working on the old API?
For example, if we start integrating the new API for the sound library, will the projects section still work with the old API meanwhile, or the projects functionality will be made un-functional until it is using the new API as well?


3. Timeline:
Do you think that you could have a rough estimation of the time needed to integrate the new API?
I would just need a rough ball park, so you could assume the same feature set as in the old app.

1. API completeness: (only the sound lib part)
I have found some points which aren't clear for me or aren't implemented:
- Server should return the list of tags (styles) for requested (filtered) files list, and this can't  be done on the client side because the client request the list dynamically and hasn't access to the full list of files.
-  Api to bind items to presets (likes previews ): I haven't found the needed api for it. (We need to clarify it if I'm wrong)
- Request the full list (pack and sounds) for the popup window:  if you want to keep the current functionality then we need an api which will work with full list for all categories.
NOTE: I am not sure but it may affect the performance
btw, it's possible to use current api by combining requests for multiple categories, but  in this case we will have problem with "sorting by" functionality, and the order of loading items is questionable.

2. Use of new and old API:
yes, it's possible to keep old api work side by side with new one

3. Timeline for the client: (sound lib)
1- new user authentication: around 1 - 2 days 
2- sound lib list and packs requests with dynamic loading: 2 - 3 days
3- upload and download: 1 - 2 days
4- manage the local changes and control the downloaded items to keep them in local data base: 1 - 2 days
5- other api (bind tag, faved, rating, bind to pack etc...): 1 - 3 days 

- Request the full list (pack and sounds) for the popup window:
I think we should try to combine various requests to load files on demand and not load the full sound library at once.
Regarding the "sort by", i'm not sure to understand the issue, as this is also present in the sound library of the main app, or maybe you were referring to the "library" types? (factory, personal ect) 

Yes, I referred to to the types. and I didn't mean that we should "load the full sound library at once"
current api offer different api for different types:
get factory: api.soundslates.loc/sounds 
get personal: api.soundslates.loc/sounds/personal
get shared: api.soundslates.loc/sounds/shared
get favorite: api.soundslates.loc/sounds/favorite

every api will return 24 items. 
if we combine the result then the list can't be sorted by name or size.
for example:
List 1: (factory)
-abc1
-abc2
-abc3
List 2: ( personal)
-zbc1
-zbc2
-zbc3

if the server return only 2 items from the list then after combining it and sort by name we will have:
 -abc1
-abc2
-zbc1
-zbc2

as you can see, the result wasn't sorted by name as before.

So the best solution would be to split the sound library of the popup version into categories like in the main app?
The user would have to select the category first (factory, personal ect) 
I guess this would solve the issue...

Yes, it's the best solution.

1. GENERAL:

Dynamic loading of both packs and list items
The dynamic loading should be available for both packs and collections.

Home page slideshow
The API should return the packs which are labeled as "featured", those will be displayed in the slideshow of the home page.
The featured packs also have an additional image URL, for the hero image of the slideshow

Popularity note of sound items
The popularity parameter is a new criteria for all items of the sound library: files and packs/collections.
It should have a numerical value, similar to ratings, but is calculated differently 

Sound library roles:
Like in the previous version of the platform, the sound library API should allow the users to have different roles (creator, designer, viewer) 


2.PACKS AND COLLECTIONS:

Creators of packs and collections

1- Audio previews: enabled only for instruments.
2- sub folders: web developers say that only 1 layer of sub folder is supported.
3- add folder to collection: the folder is added instead folder contents (please notice that if sub folders will be supported we should decide if only first layer will be added)
4- rating and popularity:  as I understand the rating value was replaced by popularity. so technically the client will use same property "rating"
5- read only packs:  server doesn't return info if the collection is read only or not for current user. but the "add to" request which return list of available packs to add to doesn't contain the read only collection.
6-Tempo: the web site tempo filter range is 0 - 200 but the client's 40-300
7-Plugin's id: this part not so clear because I can't find the functionality which will use the plugin id.
Current client/plugins side:
Client attache the plugins list (name, manufacturer, version etc) when uploading presets. this part is a little buggy because this  info is sent over IPC, and sometime client can upload preset with empty plugins list. 
to fix it I think that client could parse the presets and get plugins info (as I remember those info was included into presets as xml format) 
Current web side:
for presets and instruments it use the file extension. Like .sound = moody sampler.
for channels it count num of items in the plugins info list.

8- add to folder: no api for folder list. it was implemented only for packs (as I said in point 5) 

1- Audio previews: enabled only for instruments.

This is also needed for the channel presets and plugins presets.
All should support multiple previews, with a main preview and multiple sub previews.

2- sub folders: web developers say that only 1 layer of sub folder is supported.

It should be extended to support an unlimited amount of sub folders.

3- add folder to collection: the folder is added instead folder contents (please notice that if sub folders will be supported we should decide if only first layer will be added)
We could keep it as it is, as the users might want to group files into folders within a collection.

4- rating and popularity:  as I understand the rating value was replaced by popularity. so technically the client will use same property "rating"

This is wrong and should be corrected:
Both popularity and ratings should be supported.
The popularity note should actually be calculated based on the rating note, and other criteria such as the amount of downloads...

Note that in the current version of the MPA; the popularity has been implemented as duplicate of the rating note, because the popularity note is not available in the old Api.

5- read only packs:  server doesn't return info if the collection is read only or not for current user. but the "add to" request which return list of available packs to add to doesn't contain the read only collection.

The Api should be modified so that its returns if the collection is read only or not for the current user.
Btw, the read only or write setting is global, meaning that it is applied to all users for which the collection is visible/shared 

6-Tempo: the web site tempo filter range is 0 - 200 but the client's 40-300

The tempo range should be modified on the Api side so that it is also 40-300

7-Plugin's id: this part not so clear because I can't find the functionality which will use the plugin id.

The plugin id will be used mostly for the plugins presets and the channel presets uploaded via the plugin host.

Current client/plugins side:
Client attache the plugins list (name, manufacturer, version etc) when uploading presets. this part is a little buggy because this  info is sent over IPC, and sometime client can upload preset with empty plugins list. 
to fix it I think that client could parse the presets and get plugins info (as I remember those info was included into presets as xml format) 

OK so we should fix this in the app side by moving the presets infos registration to the client, parsing the preset file as you have suggested.

Current web side:
for presets and instruments it use the file extension. Like .sound = moody sampler.
for channels it count num of items in the plugins info list.

We have added an extensive form for plugins in the website backend.
This should allow to define a custom integration for certain plugins, for example the moody sampler using the file extension.
For plugins without specified custom integration, we should use the same system as previously used in the plugin host.

For channel presets, the server side should count the amount of plugins used in the channel, but should also be able to reference which plugins are actually in use.
The same is expected for the plugin presets (single instances used in the plugin host) 

Use of plugins ID:
The behavior we are expecting ton achieve with the plugins ID's is to be able to consistently reference the plugins and channel presets to the relevant plugins.
For example: If a plugin is called "Massive" and manufactured by the company "Native instruments"
It should be assigned a plugin ID on the server.
The website and client/plugin host should be able to retrieve all the presets and channel presets pointing to this plugin, using the plugin ID.


8- add to folder: no api for folder list. it was implemented only for packs (as I said in point 5) 

I'm not sure to understand this point.
Do you mean that the Api doesn't support adding files to folders?

9. Visible packs:
Recently we have fixed an issue with packs which were not marked as "visible"
It seems that the old Api was not handling this correctly, as the collections created were corrupted if the "visible" parameter was not selected.

We should fix this in the new Api.
If Visible enabled for a pack:

• Visible to all users in the Factory section 
• Editable by the creator of the pack 

If Visible not enabled for a pack:

• Not visible to users in the Factory section 
• Editable by the creator of the pack.

The goal for this feature is to have a system allowing us to prepare the packs before publishing them.
Without this, the packs will be displayed in the Factory library directly after the creation, even if they are still being edited.

10. Comments for presets:
This is a new feature which you should discuss with the Api developer.
For instruments, plugins and channel presets, we should add a "comment" field.
This will allow to enter a description for an instrument, preset or channel preset.
The comment can be added by the creator of the file only and should be editable when re-saving the file.

Hi Guys, please follow this discussion

8- add to folder: I mean that import dialog contain list of collections and folder. and currently there is no api to get folder list. (also as I see it will be used by "Move to" options in popup)
11- remove from: in the new task there is "remove from" option, so we also need api which return folders and collections based on the item id.
also about " This options should appear only if the files have been added to collections." if you want to enable this functionality then server should return flag which indicate that file have been added to collection.
(I amn't sure but this may affect the performance, so the web developer should decide how optimize it) I will write my view under related task or in slack.

SUMMARY:

1- Audio previews: enabled only for instruments.

This is also needed for the channel presets and plugins presets.
All should support multiple previews, with a main preview and multiple sub previews.

2- sub folders: web developers say that only 1 layer of sub folder is supported.

It should be extended to support an unlimited amount of sub folders.

3- rating and popularity:  as I understand the rating value was replaced by popularity. so technically the client will use same property "rating"

This is wrong and should be corrected:
Both popularity and ratings should be supported.
The popularity note should actually be calculated based on the rating note, and other criteria such as the amount of downloads...

Note that in the current version of the MPA; the popularity has been implemented as duplicate of the rating note, because the popularity note is not available in the old Api.

4- read only packs:  server doesn't return info if the collection is read only or not for current user. but the "add to" request which return list of available packs to add to doesn't contain the read only collection.

The Api should be modified so that its returns if the collection is read only or not for the current user.
Btw, the read only or write setting is global, meaning that it is applied to all users for which the collection is visible/shared 

5-Tempo: the web site tempo filter range is 0 - 200 but the client's 40-300

The tempo range should be modified on the Api side so that it is also 40-300


6- add to folder: no api for folder list. it was implemented only for packs (as I said in point 5) 

I'm not sure to understand this point.
Do you mean that the Api doesn't support adding files to folders?

7. Visible packs:
Recently we have fixed an issue with packs which were not marked as "visible"
It seems that the old Api was not handling this correctly, as the collections created were corrupted if the "visible" parameter was not selected.

We should fix this in the new Api.
If Visible enabled for a pack:

• Visible to all users in the Factory section 
• Editable by the creator of the pack 

If Visible not enabled for a pack:

• Not visible to users in the Factory section 
• Editable by the creator of the pack.

The goal for this feature is to have a system allowing us to prepare the packs before publishing them.
Without this, the packs will be displayed in the Factory library directly after the creation, even if they are still being edited.

8. Comments for presets:
This is a new feature which you should discuss with the Api developer.
For instruments, plugins and channel presets, we should add a "comment" field.
This will allow to enter a description for an instrument, preset or channel preset.
The comment can be added by the creator of the file only and should be editable when re-saving the file.

9- add to folder: I mean that import dialog contain list of collections and folder. and currently there is no api to get folder list. (also as I see it will be used by "Move to" options in popup)