ModPlug Central

maybe it is too early

basically:
https://hg.sr.ht/~coaljoe/tut

it is GPLv3 licensed project
it wasn't really meant to be public, there's currently issues with building it probably (but its because of sr.ht limited support for go modules mostly)
it can't be built very easily :)

basically now it looks like this (almost):
https://libre.video/videos/watch/76488fc0-39c7-4414-a51b-7ec3ae04118f

it isn't maybe useable but i did some interesting work (also)
its almost can save / edit / play its own modules now (and some imports maybe)

this is a tracker that only supports portable features
while it is somewhat modern too
this is notes on portability:
https://hg.sr.ht/~coaljoe/tut/raw/jet/portability.txt?rev=tip

and this is some notes on its internal plugin format (experimental):
https://hg.sr.ht/~coaljoe/tut/raw/jet/jet_format.txt?rev=tip

basically it supports (almost) plugins in the format called 'jet'
it is an experimental format
i did most of the work on it some time ago
it is actually *works*

this format is nearly 100 % portable (remember it doesn't support non-portable features, and it don't have 'externalities')
thus it support portable instruments (synths / generators) and portable effects
there's also jethost tool that is sortt of like lv2host, but for jet
and it works just with jack / jack messages or midi (like virtual keyboards...)

basically just works like a subset of lv2

now how it is portable ?

uhmmm it uses a VM (wasm/wasi interface) (no browser !)
that is only tiny like few mb maybe
and the effect is just .wasm file that is only few kb (and its truly portable (almost))
and maybe some .json (instead of that .ttl from lv2..)
synts just work the similar way

they're then embedded into the module, just like samples
you can reuse synths ! you can embed one synth into another module ! they work just like samples !
they don't have / need any environment they will in fact work even on risc v !
without any recompilation !

you're 12 year old plugin/module that is probably unsupported now will still work, because they're just like samples
they dont need anything to run only jethost (or jet framework)
they like don't have external dependencies (only wasm/wasi VM)

thus basically it is more like classical tracker, yet it supports (fully portable) effects and instruments
the sound will be more like in renoise (because renoise just supports virtually the same synths / effects, but renoise is not portable and thas other issues being relatively huge)

so yaeh that how it works

100 % wasm in this video (yamaha JX10 from MDA, ported to .wasm (no changes !))
and run in jethost (app)

sad that i can't embed video
i uploaded it here:
https://upload.disroot.org/r/daQTdZDw#qlCMljSyJhGEtshjOK6eXIrqxTCtfguupJRGKKyoGDk=

the jet format maybe isn't ideal but in theory it can be used futher in other works

there's also experimental format, that in theory can support more plugins (not only lv2)
but it needs more new wasm/wasi VMs and more work, currently they don't have the needed features

some plugins are harder to port (to .wasm) because they use filesystem for presets say
and they aren't initialize properly

but i was also able to port other plungs / synts (like VL1)
http://www.polyvalens.com/vl-1/

some work some not basically
far more portability in just 'effects' because they're usually more simple
you can port probably any or at least not very big (usually thats enough !)
there should be a library with the ported effects

it also has console player / library like openmpt123 / libmpt

but the code isn't very nice basically :)
and many features doesn't work (even from classic trackers)
it maybe needs more proper work

i just wanted to share the work / the research and the results that it is mostly works
there isn't anything too hard

it runs wasm virtual machine internally !

ah yes this tracker is 'somewhat modular' so the jet is technically independent

jet implementation can be reused (at least if it builts more easily..)

actually i wanted to post it to general board

Interesting approach. But I'm a bit confused why you consider internal plugins to be non-portable. OpenMPT comes with plenty of internal plugins and they run on all platforms supported by libopenmpt. Since the source is open, anyone can make them run on any platform they like to.

renoise's particular implementation is just unknown

it isn't even open source

thus it cannot be reimplemented, even if you have a source it will be very hard esp. if the author decides to change something

it is a big work overall and its something a player shouldn't really have (or player library)

same can be said say about protrekkr that even supports some 303 implementations / synths internaly that is basically no way to make them really portable
(im taliking about third party players too, basically the best if its simple; thats the reason jet is actully 'simplier' than lv2 (because lv2 is based on some unfriendly TTL/RDF (that is basically semantic web !) initialisation of pluings. and that was stripped completely in 'jet'; because it makes plugins and hosts much harder. atleast with the current wasm_preview1 that basically not fully working yet.
it took LMMS project some years maybe and they still dont have full lv2 support (!); and renoise never had it they just support older ladspa and dssi on linux.
even the author of lv2 said they should be used something more sane :)
)

and recompiling them is basically not possible for many reasons
even some small ladspa plugins are hard to fix / find proper version and so
even less so for dssi that is basically unsuported mostly at the moment

you may not even have the source

or the source of proper version

(another plus of this format is that it is less prone to having some unsupported version... because in the module you always have the version you used ! even can be different versions of the same synths ! used simultaneously !
thats nearly impossible on system-wide plugins like LV2)

i don't really know if modplug has an internal library of plugins (and what format ?) since i never used them


another example is that OPL (?) synts from s3m that is basically unportable too (they're even supported by sound card in dos ?)
they're basically never used (or implemented..)

All those arguments are just about closed-source software in general. OpenMPT is a third-generation tracker just like Renoise, all its internal DSPs / plugins are open-source and can, if required, be re-implemented in any other software. The same is true for external plugins if they are open-source. In fact the example that you mentioned (mda JX 10) is a plugin that you could use in OpenMPT, or Renoise for that matter, and you could recreate it perfectly outside of that environment due to its open-source nature. So I don't quite understand the point you are trying to make in that comparison. This has nothing to do with portability, only with source availability.

Quoteanother example is that OPL (?) synts from s3m that is basically unportable too (they're even supported by sound card in dos ?)

I think the fact that OpenMPT and SchismTracker have OPL emulation available across several platforms shows that it is very much a portable feature.

Quotethey're basically never used (or implemented..)

There has been quite a surge in S3Ms with OPL instruments since OpenMPT added OPL emulation, making the feature accessible to many users.

you can but i for instance don't want to recompile severely broken dssi nekobee for few of my modules

nor i have even the source (of the needed version, that probably not even author has anyway :) )

*and* with this plugin you can play it in winamp / any other player in original form without any hunt for source 0.1111v of nekobee dssi (unsupported)

thats the point - no deps :)

module should contain everything it needed if you want to rephrase it

(but not c compilators, in fact plugins can be written in multiple languages; not every one is a fan of c compiler...)

by internal plugins i meant built-in (native in this pic)

i don't know who has the source of them..



i don't have because renoise is just isn't open source

and even if i had there's no guaranty some implementation wont change with time / randomly as i said