I built this in v5.x on OSX years ago
I packaged it up as a 'MacOS app' with multi-res icons & main shell script 'droplet' to enhance the drag-drop experience.
As OSX is BSD and real unix, it also supports bash which I have a bunch of scripts launch ubee512 that are compatible with how I dragdrop them in windows.
The bash stuff is an "ansi bash menu skeleton" I develop for my work I find handy using over tty.
In windows I have some 'machine' scripts that can take files, and other scripts.
Fairly unorthodox but convenient. they work the same as bash scripts, bat files or windows links.
Of course they also work from commandline, I also use a script to create windows links on-masse as they use absolute links.
I have been meaning to "write a script for this" to generate microbee "machine" scripts/links.
batches are better because you can add a pause and include debug to a console outside ubee512, without adding madness to windows links. edge case you can also register app protocols in your browser(s)
An example may be a windows shortcut or a bash/sh oneliner, I might call ubee512-pc85-tapei-asteroids
"C:\ubee512\ubee512.exe --model=pc85 --tapei=mbee_asteroids_22_16bit_mono.wav"
instead if I drag the file mbee_asteroids_22_16bit_mono.wav (or shortcut)
we can use %1 in windows to drag drop a file and pass its filename to the shortcut.
I might call this ubee512-pc85-tapei and put it in my 'machines' folder with other links and batch files.
"C:\ubee512\ubee512.exe --model=pc85 --tapei=%1"
same of course applies to a batch, or a bash/shell script but you get more lines to write your code than a shortcut dialogue.
bash uses $1 and is way more civilised than dos/win32 'scripting'.
Happy to share my code / ideas / experiences. I am not sure much will have changed compiling in OSX, although I did avoid using fuse.
In the meantime I encourage migrating the code from SDL1 to SDL2.
Although its relatively mundane task, there are not many commands to deal with. This would further improve performance on older machines, however keeping backwards compatibility is too difficult I would think.
I would suggest keeping a branch for sdl1.x open a while, until a few missing features / models are sorted.
That way those old widows 7 machines on ancient GPUs can still run it.
my latest version is the public 6.0.0
is Stewart releasing 6.0.8 to the public, or can you share the source?
Thanks, David.
I packaged it up as a 'MacOS app' with multi-res icons & main shell script 'droplet' to enhance the drag-drop experience.
As OSX is BSD and real unix, it also supports bash which I have a bunch of scripts launch ubee512 that are compatible with how I dragdrop them in windows.
The bash stuff is an "ansi bash menu skeleton" I develop for my work I find handy using over tty.
In windows I have some 'machine' scripts that can take files, and other scripts.
Fairly unorthodox but convenient. they work the same as bash scripts, bat files or windows links.
Of course they also work from commandline, I also use a script to create windows links on-masse as they use absolute links.
I have been meaning to "write a script for this" to generate microbee "machine" scripts/links.
batches are better because you can add a pause and include debug to a console outside ubee512, without adding madness to windows links. edge case you can also register app protocols in your browser(s)
An example may be a windows shortcut or a bash/sh oneliner, I might call ubee512-pc85-tapei-asteroids
"C:\ubee512\ubee512.exe --model=pc85 --tapei=mbee_asteroids_22_16bit_mono.wav"
instead if I drag the file mbee_asteroids_22_16bit_mono.wav (or shortcut)
we can use %1 in windows to drag drop a file and pass its filename to the shortcut.
I might call this ubee512-pc85-tapei and put it in my 'machines' folder with other links and batch files.
"C:\ubee512\ubee512.exe --model=pc85 --tapei=%1"
same of course applies to a batch, or a bash/shell script but you get more lines to write your code than a shortcut dialogue.
bash uses $1 and is way more civilised than dos/win32 'scripting'.
Happy to share my code / ideas / experiences. I am not sure much will have changed compiling in OSX, although I did avoid using fuse.
In the meantime I encourage migrating the code from SDL1 to SDL2.
Although its relatively mundane task, there are not many commands to deal with. This would further improve performance on older machines, however keeping backwards compatibility is too difficult I would think.
I would suggest keeping a branch for sdl1.x open a while, until a few missing features / models are sorted.
That way those old widows 7 machines on ancient GPUs can still run it.
my latest version is the public 6.0.0
is Stewart releasing 6.0.8 to the public, or can you share the source?
Thanks, David.