ARM BASIC: SOUND extension?

Thanks, Acorn.

Acorn may have been expecting you to make more use of the eight letter description, rather than “PPD”.
Do you remember the transition between DOS and Windows, how many things broke when Word decided to claim “.DOC” for itself? And how many entirely different “.BAS” files exist?

At least AB7 and FBA are entirely different types with their own icons and run actions…

Rick, when you apply for a filetype you provide a lot of supporting documentation.

In my case I included a full description of the file contents, its full name, a description of what is was for and how it would be used, and reference to the Adobe Technical Note #5003 that defines the format.

I don’t know what else I could have done short of hitting someone around the head with a printed copy. Wrapped round the PostScript Red Book.

No, it was the “confidential” thing.

At least AB7 and FBA are entirely different types with their own icons and run actions…

And MIME maps… oh, wait…

It was just inept. There has been, historically, a shortage of ept.

There has been, historically, a shortage of ept.

To be fair, that’s afflicted pretty much the whole industry, not just Acorn & its associates.

And MIME maps… oh, wait…

Ah, there we are back to the problem of short file extensions where the official allocation method seems to be “biggest player wins”. As I said, quite a few non-Word files were .doc prior to Word, and on my system VB has hijacked .bas even though it was used by different things before.

Even more amusingly, .jpg and .jpeg extensions have two different icons and open up in two different programs. As .jpeg works, and that’s what I use, I’ve not bothered to fix it.

Point is – I’m not sure there’s really a definitive solution to how to handle file type behaviour. Both extensions and metadata types have potential problems. We just need to do the best we can with the methods available and the lack of epts and unicorns in general circulation.

FWIW, I prefer file types. No rubbish attached to the file name. Unfortunately it completely breaks on… pretty much everything else.

MacForks were even better in some ways – this text file opens in this editor, but that text file opens in that one.

This is another thing I considered for a Filer, but I could only really see it being useful for Sprites – this spritefile of icons opens in Paint, but that 20MB spritefile artwork opens in PhotoDesk.

Speaking of sprites, today’s project was to write “Pnglu”, an alternative to spritefiles full of icons that are rarely used. PNGs are much smaller than sprites – about a third the size in something I was working on. And if you don’t need extreme speed, PNGs are very useful. However, they’re awkward to work with in RISC OS because you end up with directories full of individual icons. Hence Windows’ ICO format.

But we can do better than that. Pnglu glues PNGs together (see what I did there?) into a Spritefile-like bundle, so each has a name. A single file is much more convenient, and named PNGs are better than the numbered PNGs in an ICO, for example.

2MB gif elsewhere in consideration of Rick’s piece of wet string

Being SpriteFile-like means that even in the absence of additional support code, we can use various SpriteOps to load and interrogate the file, find individual PNGs and even manipulate them:

Mind you, this is on 15-year-old RO4 with built-in PNG support.
I’m not trolling, I’m just saying. ;-)

NTFS also supports forks, because it’s an NT feature albeit seldom used. In a sense the whole !Foo subdirectory scheme for applications is like a less abstract version of forks, and also potentially more powerful.
I’ve been through losing the resource fork on Macs enough a long time ago to know that they can be a gigantic PITA when working across platforms.
Oh, I drifted rather off topic.

Mind you, this is on 15-year-old RO4 with built-in PNG support.
I’m not trolling, I’m just saying. ;-)

Yes, shame we don’t have little features like that in RO5.
Anyway, move on, nothing to see here.

Nemo – whenever you think of features like that you’d like to see/add to RISC OS5, why not send an email to us at RISC OS Dev with a quote to do the work? You’ve got the skills :)

That would feel extraordinarily mercenary and self-serving.

All contributions gratefully received…

Tristan reminded us

NTFS also supports forks

Yes, a proper journaling filing system is brilliant… right up until you have to move something elsewhere. Mind you, an FS with centisecond accuracy is marvellous until you try to do an incremental backup across Samba.

When I wrote

MacForks were even better in some ways

I meant the Mac’s use of a FourCC for filetype, AND a separate FourCC for “owner”, so that files generally loaded in the program that last edited them. I am getting a bit cheesed off with being surprised by what application pops up when I double-click on something. Hence my thoughts about the Filer. I’ve been doing a lot of fiddling with Filers.

I’ve experimented with different types of metadata in RISC OS, but it always ends up going in only one direction…

In a sense the whole !Foo subdirectory scheme…

And the portable and increasingly important equivalent for files – OPC (minus the XML of course, I’m not insane).

The advantage being that (on the whole) one can attach any kind of metadata to the “file” in such a way that it cannot be detached (unless the file is edited, by some editors, unfortunately).

That would feel extraordinarily mercenary and self-serving.

I do not follow that!
Surely it would only be mercenary if the quote was a significant amount rather than nominal?
And it would be community serving if as a result it became available to all as part of RISC OS?

That would feel extraordinarily mercenary and self-serving.

Well, you could always quote a figure of “Free of charge” and just feed back your changes to RISC OS 5 for us all to enjoy.

Or you could just keep adding features to your own private version of RISC OS and keep taunting us about them on here! :P

Or you could just keep adding features to your own private version of RISC OS and keep taunting trolling us about them on here!

There. FTFY.

Or you could just keep adding features to your own private version of RISC OS and keep taunting trolling us about them on here!

There. FTFY.

Did I miss a marker in the diary for “kick Nemo day”?

I’d much rather agree with Andrew Rawnsley and Martin that we would quite like it if you (Nemo) would like to spend a little time revamping things and both adding features while removing long standing ‘quirks’ we would all be truly grateful.
Andrew looks to be offering thanks that the bank manager understands. Might not match the going rate, but will probably keep you in coffee and chocolate hob-nobs¹ for a while plus that “I fixed that” inner glow.

¹ “Other beverages and munchies are available”.

I’d much rather agree with Andrew Rawnsley and Martin that we would quite like it if you (Nemo) would like to spend a little time revamping things and both adding features while removing long standing ‘quirks’ we would all be truly grateful.

I’ve no issue with Nemo doing paid work on RISC OS, that’s great, but as he suggested he wasn’t comfortable being paid for the work, I was suggesting he could always submit his features & bugfixes for free rather than sitting on them, and we’d all be just as grateful.

Did I miss a marker in the diary for “kick Nemo day”?

There was no intention to kick. It’s simply that nemo has posted many animated GIFs of impressive things – things that really deserve wider appreciation.

plus that “I fixed that” inner glow.

Uh… Remember who we’re talking about. ;-) It seems like half of his posts are the verbal equivalent of banging forehead to desk surface.
Here’s a nice example: https://www.riscosopen.org/forum/forums/12/topics/11736#posts-81218

Okay, okay, let’s start off small and pretend that lumping all sorts of important stuff together isn’t really happening. At least it appears as if the filesystem drive maps are now held in Dynamic Areas and… holy crap, they’re read only in USR mode. Whoo-hoo! Progress!

Yes, just to clarify, RISC OS Dev’s goals are entirely altruistic (more or less). We’ll fund work that we then give away as part of Open Source RISC OS.

Obviously if the quote is low, that’s great, because we can make the pot go further. But, it doesn’t have to be, is all I’m saying, provided there’s a sense of value for money.

The bottom line is that both Richard and I are pig sick of this whole feature discrepency between RO5 and Adjust etc. Sometimes I feel that there are some folks who actually “relish” RO5 being feature poor as some kind of “purity”! ROOL sometimes ask for our “vision” for RISC OS, and my overriding one is for forward progress and momentum on all fronts, and that means making sure that RISC OS 5 isn’t stuck with a feature set from 1999!

So, erm, yes. I’d like it if the talented folks that are still around were all shooting in the same direction. And Nemo is definitely one of those talented guys :)

as some kind of “purity”!

Purity? Neither version is “made by Acorn” so the only claim to purity is surely running on native hardware; and the future here is RISC OS 5.

feature set from 1999!

USB, FullHD (and greater) display modes, modern contemporary hardware…

What you mean is RO5 has fewer glossy features but rounded icons won’t suddenly make a UI from the ’80s look like one from the ’10s. ;-)

Could be worth asking again what features people actually want. The bounties are more for updating and modernising existing components than something that RISC OS 4 has.

More realistically – just to kick out an idea – what might be involved to provide RISC OS with an image loader subsystem. The OS can handle sprites, while other helper modules can provide support for JPEG (removed from SpriteExtend) as well as any other desired format such as PNG, BMP, GIF, etc. The process should be similar to the JPEG calls (info, plot from file, plot from memory) with the addition of a whip-around call to say “here’s a file/memory block, do any of you recognise the format?”.
Saving and exporting should be considered, but deferred for a future time. Work on ability to have RISC OS handle more image file types for itself.
That’s my idea – anybody up for discussion about practicalities of implementation?

ImageFileRenderer?

ImageFileRenderer?

Yes, that was what I was thinking of.

Is the behaviour/specification good or are there things to change? As it’s unlikely that source will be available and the RO4 handlers will be 26 bit, this would be a new implementation.

What strikes me is the scaling mechanism. Is this supplied by the OS or does each renderer need to scale for itself? Is there any potential way to improve this? I notice that native JPEG scaling is rather rubbish (no attempt at anti aliasing). If scaling (and other stuff) was a separate step (no idea how – just thinking aloud) then it could potentially be improved, or given a “quality” setting to allow speed/quality tradeoffs.

Is the behaviour/specification good or are there things to change?

This is one of those situations where I’m sure that someone grumbled about it at some point, but I can’t remember who, when, or what.

On the other hand, having something is likely to be better than having nothing, and a plain implementation of ROL’s APIs/features will provide compatibility with software that was written for ROL’s OS.

Sometimes I feel that there are some folks who actually “relish” RO5 being feature poor as some kind of “purity”! ROOL sometimes ask for our “vision” for RISC OS, and my overriding one is for forward progress and momentum on all fronts, and that means making sure that RISC OS 5 isn’t stuck with a feature set from 1999!

I rather adopted the mindset that it wasn’t worth the angst of not having so I concentrate on what is present.

It would be nice if useful source came from the other fork, but that may never happen so it’s a case of fostering the reproduction of features¹ where we do have access to the source.
That said last time we had a “chat” about the features from Select/Adjust the list we came up with didn’t seem that long. We will ignore Rick’s rounded icons phobia – you can switch them off in Adjust anyway.

As it’s unlikely that source will be available and the RO4 handlers will be 26 bit, this would be a new implementation.

1. As Andrew has already shown with the exchange of views before/at the RO purchase never say never.
   There might be source gifted, VRPC might in future be sold with a copy of an updated RO5 that contains all the features
2. I could have sworn that Justin’s Rambles mentioned having finally made the code bit neutral. Obviously certain newer behaviour wouldn’t be catered for – Zero page, alignment, SWP instruction etc.

¹ One day I may feel that I can pass over something worthwhile of my Filer mods² so that others can try out the extra key shortcuts and mouse movement (trying to sort the clicky bits now)
Then again I may find Nemo rebuilt the Filer and Wimp etc and it sports all the little tweaks with a user configurable key shortcut set etc. so that what I’ve been playing with is entirely redundant

and a plain implementation of ROL’s APIs/features

Now let me throw the cat right amongst the pigeons… Apart from necessary bits in the OS itself, this is going to be written in C, isn’t it? Does the API still hold?

Indeed it is worth considering new features to be written in C. I know C has its issues, but then again so does a mass of assembler, and generally speaking it’s less problematic to rebuild something with a suitably up to date compiler than to pick through looking for whatever instruction sequences are causing issues… The future should be “less assembler, more HLL” (and we don’t really have many options here!).

wasn’t worth the angst of not having

I never had, never figured the available features were enough of an improvement over 3.7 to justify the price. Note well that I left the UK (and everything online) in 2002, so any additions after early 2002 won’t have been factored in.

Anyway… So, going from 3.7 to 5, it’s not so bad. ;-)

list we came up with didn’t seem that long

Yes, I remember there’s a long list of “what the other one has”, but when pressed the list shrunk dramatically.
Thing is, you’re asking where OS5 users hang out. The same question where OS4 users hang out might elicit different priorities.

We will ignore Rick’s rounded icons phobia

:-p Not a phobia, just extracting some urine for levity. Shall I talk about green directory icons instead?

has already shown with the exchange of views

Yes, it’s a great start.

finally made the code bit neutral

The code itself, yes I think it is… if not neutral then able to be switched – part of the A9home work. Though the OS is not specified as being feature complete so clearly there are some things still not done.
However this is only useful if the code is available. I was thinking more about existing modules. I don’t think there’s anything from the RO4 world that we could hope to make use of as it stands right now.

Thing is, you’re asking where OS5 users hang out. The same question where OS4 users hang out might elicit different priorities.

As I recall at least one contributor (not so Grumpy Dave) is a regular Select/Adjust user and has tried RO5 but misses various features. I think his views on missing items revolved around Filer behaviour¹ and the ImageFileRenderer features.

However this is only useful if the code is available.

There was a might in my comments.

I was thinking more about existing modules. I don’t think there’s anything from the RO4 world that we could hope to make use of as it stands right now.

Given the alterations to the core OS made simply to allow more modulisation I’d say hacking a RO4.3x into RO5.x probably ain’t going to work, but then there’s the good neighbour element where a good neighbour asks rather than appropriates.

All speculation anyway – unless Andrew knows different.

¹ Filer display options and shortcut keys essentially. For the latter I’ve looked at which keys were used for various things and while some are sensible the others show no logic whatsoever and are decidedly not intuitive. The selection of a few on this side of the fence is dodgy too.

Now let me throw the cat right amongst the pigeons… Apart from necessary bits in the OS itself, this is going to be written in C, isn’t it? Does the API still hold?

Yes. Image file renderer implementations use a workspace pointer in R12, so standard CMHG veneers can be used to wrap the core C code.

A teeny tiny bit of assembler will be needed when an implementation calls a colour mapping function, but I think that’s about it.

Indeed it is worth considering new features to be written in C. … The future should be “less assembler, more HLL”

I thought that was the generally accepted opinion for at least the past 10 years.

I thought that was the generally accepted opinion for at least the past 10 years.

Speak for yourself¹!

Apropos of nothing, I finally got so cross about something I made a GIF…

And decided in a fit of misplaced altruism to fix it… but on the way there (in fact trying to find where “there” might be) I stumbled upon the Wimp_ProcessKey code and recalled that I’d previously complained that the UTF-8 handling of yore broke ProcessKey in annoying and exciting ways (eg WPK,&101 works fine, but WPK,&100 sends null to the focused task, and it also trampled on some of DeepKeys’ functionality)… so I’ve fixed it!

It’s slightly too large to be considered a patch and I did it With The Actual Source (unusually for me), so I should probably send the diffs to someone to actually try. Volunteer?

Andrew wrote

both Richard and I are pig sick of this whole feature discrepency between RO5 and Adjust etc.

Hear hear, and I’ve been saying this for a very long time. I don’t care about any one version, I care about the cumulative API. The very Acorn concept of backwards and forwards compatibility (distributable soft-load modules) was discarded for purely self-serving reasons by ROL, and that’s part of the reason I never supported them. It doesn’t get any more excusable when dressed in “but this is the active development branch” quibbling. API is API.

Sometimes I feel that there are some folks who actually “relish” RO5 being feature poor

Sadly it’s human nature to discount what you can’t have. But “Selection and cut-n-paste in icons? Pah! Who’d want that?!” is just silly. It’s ridiculous RO5 does not have this. Embarrassing. Meanwhile, “I’ve partially ported the OS to a weird architecture that only 3 people own” and it’s applause all round. I do wonder if anyone actually uses RO5 for anything.

As for the GIF, the Wimp’s innocent “I’ve no idea how the pointer got from that menu entry to the other side of its submenu arrow so I certainly shouldn’t open the submenu!” is something I trip over many times every day, so I’m going to fix it at some point.

¹ Levity aside, I’m all for people writing new stuff in whatever language most facilitates their efforts and aids future support. But I’m seriously unimpressed with someone shoehorning one C routine to do something bleedin trivial into an otherwise pure ARM module. I’m looking at you, RO4. One man’s “it’s easier to debug” is another man’s “if you were finding that hard, perhaps you should find another hobby”.