I'm making a music tracker - possible RISC OS port

Hello,

I’m working on a music tracker type program. I’m writing it for linux, with Xlib for the GUI and ALSA for playing the sound.

This is entirety a ‘for fun’ sort of project. But at the same time, I’ve been aware that today, there’s not a lot of music software available for RISC OS. I have the impression that a lot of the software that there once was was lost because of the 26/32 bit problem.

This project may be an opportunity to give RISC OS some much needed new software for this specific task.

I’m writing it in C.
As the GUI for linux will be built on Xlib, it probably won’t be possible to bring that part over to RISC OS. At the same time, it would be ideal for the program to have a RISC OS native GUI that follows the RISC OS design conventions.

So I wanted to ask, would anyone be interested in helping with the RISC OS version of this project? I would need help designing the UI for the RISC OS version, as well as other problems related to programming on RISC OS.

Can’t help much here, but I’ll sure use it :)

As the GUI for linux will be built on Xlib, it probably won’t be possible to bring that part over to RISC OS. At the same time, it would be ideal for the program to have a RISC OS native GUI that follows the RISC OS design conventions.

What’s the purpose of the GUI?
Just allowing the user to set options?
Options stored in a text configuration file? If so there’s an obvious answer for much of the config work.

there’s not a lot of music software available for RISC OS. I have the impression that a lot of the software that there once was was lost because of the 26/32 bit problem.

If you’re referring to trackers then there’s quite a few 32bit compatible trackers available. TimPlayer, QTM, both of which have GUI elements if you want them. There’s also shims for many tracker Modules to both TimPlayer and QTM. The rest I’ve converted to 32bit. Most of these are bundled with ADFFS.

What’s missing is composition suites, I think DesktopTracker was converted but I seem to recall there being issues with page zero access due to some quirks in the way the SetMemory SWI is implemented. There’s a thread covering it here and many more in the SoundTracker section on JASPP covering ones that have been shimmed or converted.

Hello,

If you’re referring to trackers then there’s quite a few 32bit compatible trackers available. TimPlayer, QTM, both of which have GUI elements if you want them. There’s also shims for many tracker Modules to both TimPlayer and QTM. The rest I’ve converted to 32bit. Most of these are bundled with ADFFS.

It looks like we’ve got different ideas of what ‘tracker’ means. I’ve been using the word ‘tracker’ to mean what you seem to be calling a ‘composition suite’. I’ve been using the wikipedia page’s definition:

A music tracker (short version tracker) is a type of music sequencer software for creating music.

https://en.wikipedia.org/wiki/Music_tracker

What’s the purpose of the GUI?

Here are a few of the things I can think of that the GUI will need to allow the user to do:

• edit patterns
• edit orderlist
• load/unload songs
• load/unload samples
• edit instruments (sample tables, envelopes, etc)
• edit samples (delete waveform points, edit sample loops & related options, adjust tuning, etc)
• edit channels (add/remove channels, edit initial channel volume/pan/etc settings, mute specific channels, etc)
• manage playback (play/pause/stop, etc)

If things go well, I’ll hopefully have an early working version (for linux with the xlib-based GUI) in about 7 months from now.

I’ve been thinking more about this. I’ve got a basic design plan in mind now. Before I was referring to it as a ‘music tracker’, but now I’m calling it a ‘music suite’ to avoid confusion.
It will be made of several parts that are combined to create the product itself, the JohnsonTool Suite.

JohnsonTool is the tracker GUI/song editor. The JohnsonEngine is responsible for making the sounds, and the SongPlayer interacts with the JohnsonEngine by telling it what sounds to make and when.

The design phase is going well and I might have the first release candidate version ready by January next year.
Until then, here is a demo song made with a very early prototype version: https://www.youtube.com/watch?v=wLv48a3NA24

the JohnsonTool Suite

Something in my mind linked that to Terry Pratchett and B.S. Johnson. In which case “JohnsonTool” is tautological.

I’ve been making progress with this. It’s still in the design phase, but now I have a test program that can generate square waves and saw waves. I swear on my life that I might be ready to release within 6 months.

Don’t rush! ;-)

When RDSP was released I lamented that its reliance on OS_Word,7 means that it didn’t work with later RO4/6 versions of Basic, which skip OS_Word,7 for no good reason. So I thought it would be straightforward to knock up a module that redirected sounds through OS_Word if they hadn’t come that way. Ought to have been easy. Could not get it to work.

The other day I returned to it and realised that RO4/6’s Service_SoundControl service call uses a unique set of parameters different from both OS_Word,7 and the Sound_Control that issued it. So I fixed that and got it to work. Result: A couple more example files worked, but no difference for most, because Sound_Control doesn’t always emit Service_SoundControl.

So now I’m going to have to intercept the Sound SWIs to achieve the same effect. But so many other interesting things to do…

In which case “JohnsonTool” is tautological.

JohnstonToolOrgan?

JohnstonToolOrgan?

Indeed. “My organ is a Johnson” being the original phrase I recall. T.P. RIP

I don’t wish to boast, but it’s a double manual. I’ll stop now.

I’m still planning this project and I’m confident that I will be releasing an early prototype version in June this year.

Planned features:

• Xlib graphics and use of Unix pthreads
• the ability to generate square wave, saw waves, triangle waves, sine waves
• the ability to play back 16bit/8bit signed samples
• embedded scripting language, PENIS (program electronic natural instruction script) which would enable users to implement their own wavefunctions or effects processing

You MIGHT want to rethink that acronym.

I wrote a SoundTracker-compatible system donkeys years ago (!HQ-Tracker) which pushed things forward a bit with a proper SWI interface, allowing real programmatic control of things. Never seemed to get any traction, although I still appear to have the source to it. Those were the days…

You MIGHT want to rethink that acronym.

Oh, I think it probably took a good few minutes to think up some words to fit the acronym that didn’t sound completely fake.

Of course, Patrick, you do understand that you must always write the name of the scripting language in full each time? Never refer to it by acronym. That’s for the end-user to “discover”.

:-)

I still think the best reorganisation was when we became Business Units rather than Departments, Divisions, Directorates, etc. which had already been used. The heads of such units were, of course, managers (previously the organisation was a technical one and the head post was an Engineer – e.g. ‘Nuclear Operations Engineer’ as it was obvious that a qualified engineer could do the simple tasks demanded of a manager, as outlined in the Dilbert cartoons). They didn’t see this coming but we had. It seemed obvious that there would be a lot of Business Unit Managers.

https://worldwideinterweb.com/20-worst-acronyms-ever/

You’d have thought, these days, anybody with a cute acronym would toss it into urban dictionary to check that it doesn’t have… meaning… in less salubrious contexts.

I suspect some of those are deliberate; I’m pretty sure “Southern Eastern Xpress” is, at least!

We have some “File And Print” servers at work…