Add tag field to remote browser

dagargo commented 3 months ago

For Elektron sounds and MicroFreak presets, it could be possible to show a column in the remote browser with the tags or category stored in these.

Related to #110.

dagargo commented 3 months ago

Summit single patches and MicroFreak presets show the category in the information column in the remote browser.

dagargo commented 2 months ago

Looks like getting the tags from the Elektron sound files (binary data) is far from immediate.

This is the content of a preset having the SYNT and TXTR tags.

$ hexdump -C -v ALARM.dtdata 
00000000  ac 11 d3 03 02 00 04 00  08 30 30 38 39 00 00 00  |.........0089...|
00000010  03 00 00 00 00 00 00 00  11 00 00 00 a0 01 0c 00  |................|
00000020  00 00 7f 51 be ef ba ce  00 01 00 b1 22 00 41 4c  |...Q........".AL|
00000030  41 52 4d 00 55 4e 44 10  00 00 02 00 f0 08 70 00  |ARM.UND.......p.|
00000040  04 00 40 00 09 00 05 00  00 00 01 00 42 0d 40 45  |..@.........B.@E|
00000050  01 00 70 01 49 1b 00 f1  16 00 00 00 16 00 01 00  |..p.I...........|
00000060  6b 69 34 b5 1f 2e 5f 00  3f 00 00 00 40 00 22 00  |ki4..._.?...@.".|
00000070  7f 00 40 00 71 f1 18 2b  27 59 40 00 77 34 27 00  |..@.q..+'Y@.w4'.|
00000080  0f 02 00 07 12 01 1b 00  c2 01 00 01 ab d7 3c 6c  |..............<l|
00000090  33 00 00 03 30 12 00 a0  00 12 00 13 00 00 ba ce  |3...0...........|
000000a0  f0 0c 00 00 00 00 8e 5c  7f 6c 00 00 00 87 aa a1  |.......\.l......|
000000b0  da aa                                             |..|
000000b2

This is the content of the same preset after removing the tags. It's larger and there are many places that have changed.

$ hexdump -C -v ALARM.dtdata 
00000000  ac 11 d3 03 02 00 04 00  08 30 30 38 39 00 00 00  |.........0089...|
00000010  03 00 00 00 02 00 00 07  01 00 00 00 a0 01 0c 00  |................|
00000020  00 00 8f f0 02 be ef ba  ce 00 00 00 02 00 00 00  |................|
00000030  00 41 4c 41 52 4d 09 00  05 02 00 f1 04 70 00 70  |.ALARM.......p.p|
00000040  00 04 00 04 00 40 00 40  00 11 00 00 00 05 00 01  |.....@.@........|
00000050  1c 00 00 06 00 b1 42 0d  40 00 40 45 01 00 70 01  |......B.@.@E..p.|
00000060  49 14 00 f0 08 00 00 16  00 01 00 6b 69 34 b5 1f  |I..........ki4..|
00000070  2e 5f 00 3f 00 00 00 40  00 00 00 7f 19 00 f1 02  |._.?...@........|
00000080  00 22 00 7f 00 40 00 71  f1 18 2b 27 59 40 00 77  |."...@.q..+'Y@.w|
00000090  34 15 00 02 47 00 01 07  00 a1 01 ab d7 3c 6c 33  |4...G........<l3|
000000a0  00 00 03 30 11 00 b0 00  00 12 00 13 00 00 ba ce  |...0............|
000000b0  f0 0c 00 00 00 00 20 d8  af c8 00 00 00 97 aa a1  |...... .........|
000000c0  da aa                                             |..|
000000c2

dagargo commented 2 months ago

After all, it is really easy as the tags are inside the metadata file.

$ elektroid-cli elektron-data-ls 2:/soundbanks/A | grep 045
F 0012 1 1       160B 045 FLASHBACK
$ elektroid-cli elektron-data-dl 2:/soundbanks/A/45/.metadata
$ cat FLASHBACK.dtdata.metadata 
{"metaversion": 2,"sample_references":[ ],"tagmask_src": {"offset":8,"size":4,"count":1},"sound_tags":[  "TEXTURE",  "CHORD" ]}

szszoke commented 2 months ago

It might not matter now but could it be that the binary data got migrated from an older version to a newer one and that's why it looked so much different after you changed the tags?

dagargo commented 2 months ago

Never thought about that. It sounds like the most probable reason.

dagargo commented 1 month ago

Added to master in 5c502d67f819f3c5863d706927793ce5396d1bf7 and improved in the following commits.

One caveat though, now listing files is slower as the .metadata file needs to be read.

c3aeb12375975894415b7ab4ffb5aa4190b4a851 added a solution to improve the speed when listing files from internal functions that didn't require the tags.

dagargo commented 1 month ago

@szszoke, feel free to reopen in case this isn't working as expected.

szszoke commented 1 month ago

@dagargo I will be able to test it sometime next week. Thanks!

szszoke commented 1 week ago

This seems to work well.

szszoke commented 1 week ago

I compared the same feature with Elektron Transfer and there it seems instant. That makes sense since they are doing less work.

I am thinking that if Elektroid would first try to get the directory list and then it would try to load the metadata then it would make the UI feel faster.

It should be possible to interact with the list while the metadata is loading and there could be some sort of placeholder shown there so that it is visible that something is going to appear in the info column but it is not loaded yet.

The placeholder could be just a rectangle with some rounded corners and some gradient animating within it. We could randomize the width of the placeholder between some lower and upper bounds and I think that would look quite good.

szszoke commented 1 week ago

One question is what to do when the user does something that would result in data transfer while the metadata is loading

should the metadata loading be finished first or should it be paused?
should it be possible to have both behavior and let the user select?
should it just show up as another operation in the table on the bottom with a progress bar?

dagargo commented 1 week ago

I compared the same feature with Elektron Transfer and there it seems instant. That makes sense since they are doing less work.

What do you mean with "same feature"? Do you mean sound listing? I've tried Transfer 1.8 and there is no sound category. Probably I understood you but I want to be sure.

Before entering into discussion, it is worth explaining the internal design and how it works:

An iterable struct is initialized. The GUI browser is locked while this operation runs and a loading spinner is shown. For the Elektron devices, this is instantaneous; but for others, it performs the whole loading and might take a lot. This depends on the MIDI API that the device presents and the actual implementation.
Once the iterable struct is filled up, the spinner disappears, the browser becomes insensitive and the loading process starts. Loading the items is performed by calling next on the iterator, then the item is filled up and the row is added based on this struct. When this operation ends, the browser becomes sensitive.

The separation of these stages and the spinner were added to make the GUI more responsive while supporting really slow devices whose loading times are really high.

So, regarding the post-loading decoration, it makes sense but implementing this would need lots of testing and many things should be considered. From the user POV, it would be fast and the

A new member in the fs_operations struct is needed.
A new cancellable thread is needed.
The thread would need to be stopped from quite a few places. For instance, when manually or automatically reloading or when moving items into. For every one of this calls, the thread will be stopped and it will take a moment to perform this (the time it takes for the current operation to run).
This is kind of incompatible with the search function unless than the search skips this entirely or performs it during the searching.

So, it is possible but complicated. Maybe it is better to remove this feature completely. What do you think?

For version 3.2, I have a few things in the backlog and one of them is having a settings window. We could add an option for this to indicate if users want the sound information or not.

dagargo / elektroid

Add tag field to remote browser #125