Where are the included binaries from?

[dromer]

There are two included binaries in the res/ folder for which it's unclear what their origin is.

It's the files gateseqpatterns.bin and sync3scales.bin.

Do you have some more info on these files? where they generated by you, and then how? If not, is there some attribution/license available?

[liquidcitymotors]

Hi @dromer, glad you asked! Those are generated by a development version of our Viaflash utility.

They are part of a larger attempt to refactor all Via modules to read compiled binary data for static resources such as wavetables, scales, and patterns.

This would allow the user, through the aforementioned app, to customize the resources on the Via modules, both hardware and software, without needing to recompile the module source code.

I did some really major work on this project last year, but frankly I had to take a break to see if it was worth it to see the Viaflash/Viatools editor project to completion. I'm hoping to put together some beta builds of the editor in its current state to accompany our upcoming release of the v2 Rack plugins.

If editing pattern banks on GATESEQ or scales on SYNC3 interests you at all, I would warmly encourage you to try compiling and using the development version of the editor and opening issues on that repo as needed. I can almost guarantee that things won't go smoothly, but I would be eager to help!

As far as licensing goes, I honestly don't have a good intuitive sense of what would be appropriate. Generally, I would hope that these binary files could be shared freely amongst users of the Via modules. I would welcome any suggestions towards that goal.

Hopefully this clears things up, but please re-open and ask any further questions as needed.

[dromer]

Thnx! we're about to include your v2 Rack plugins in our Cardinal project so wanted to clear up any issues with these files: https://github.com/DISTRHO/Cardinal/pull/173

It might be good to apply simple CC0 licensing to such "public domain" files.

[liquidcitymotors]

Ah I see, happy to help get our stuff included. I want to take a closer look at our licensing documentation for the project as a whole while I'm addressing this, but I'll get the licensing info updated imminently then close this issue when that's sorted.

Let me know if I can help at all with any issues you folks are having with context menu stuff, I do really hope to add this same binary resource format to the rest of the modules in upcoming revisions and have a public release of the editor.

[falkTX]

question on those binary files, are those architecture or system dependent? say, will a x64 work on ARM and vice-versa? what about linux vs mac vs windows and more? I tried to look for the exact part of the code where the "decoding" of such binaries happen, but your repository setup is a bit complex, it is a bit hard to find this info.

[dromer]

These are not "executable" binaries as such, more like a binary payload that gets parsed no? Whether the parser is done in x64/arm/avr doesn't matter.

[falkTX]

ah, so like a tar or image or audio file, its own custom format. would be nice then to give them a custom file extension instead of the generic .bin

[liquidcitymotors]

Discussion like this really helps me untangle things on our end, thanks everyone.

My working understanding is that these binaries aren't system dependent, and the same binary works fine on the 32 bit arm cortex m4 in the hardware modules with different alignment and endian-ness.

100% these will get a custom extension, great suggestion.

I'll need to sort that out over in the other repository, and I'll see if I can make the connection between different parts of the Via codebase more apparent in the process. It all gives me a bit of a headache and I wrote the damn thing.

This issue seems like a good place to collect discussion about how Viatools (the resource editor) interfaces with Rack so I'll keep it open until something sane is established.

[dromer]

@liquidcitymotors as a headsup in Cardinal we don't use the blocking osdialog calls but instead use an async method for filehandling. You may expect an incoming patch that allows this :)

[dromer]

@liquidcitymotors I finally got around to start working on your modules and will open a PR for this soon!

Also noticed you went for custom file extensions which at least makes it more clear what these binaries are. So I think we can probably close this issue?

[liquidcitymotors]

Awesome news @dromer , lets close this. The generation tool itself is stalled at like 98% completion, maybe the Cardinal versions will catalyze us to finish it :) Let me know if I can help any further.

[dromer]

@liquidcitymotors haha, so it goes.

We just released 23.10 with mostly bugfixes and the coming 23.11 will likely focus on some new and updates modules. After we've tested/vetted the changes I made we'll send that PR back to you :)

[dromer]

@liquidcitymotors that PR is now open.

Would you mind setting an explicit license on these binary files? Or would you say they fall under the project license just like any of the artwork files?