New Voice Generator Software

I tried Archimedes Gamemakers’ Manual example programs, including MusicMaker. The last lets you create your own customised sounds and sound modules for your game files written in BASIC. I have been searching for WavGen32 over and over again and I was always directed to a website hosted by David Saunders to no avail. The links to the web pages to download that program for RISC OS up to now proved fruitless.

I need a program like MusicMaker but which lets you produce sounds with more intricate controls so you can program pitch bending within the sound you are creating, among the features.

What I wish for is a program like the MusicMaker program written in BASIC, which is part of the Archimedes Gamemakers’ Manual collection. But it should be as such like Audacity, an audio recording/playback and sound generation program available for Windows and Mac computers, as far as I know.

I downloaded !WAV_Gen from this website:

http://www.audiomisc.co.uk/software/index.html

But the only thing I got was an “Internal error,” after I selected the (16 or 24-bit) bit process size and sample rate.

I am in the middle of practising of coding in BASIC for a series of video games and I am looking for a voice generator tool like MusicMaker that lets you alter the pitch in a scope beyond the settings of the speed and depth rates of the sampled sounds, like a pitch bend, as the latter is a common feature in MIDI files and software for creation and playback of MIDI files.

I downloaded !WAV_Gen from this website: http://www.audiomisc.co.uk/software/index.html

Ah, now that’s Jim Lesurf’s web site, and he tends to include the source (as he has done with that download)
If you have questions about that specific software I’m sure Jim can answer.

I downloaded !WAV_Gen

But the only thing I got was an “Internal error,” after I selected the (16 or 24-bit) bit process size and sample rate.

So it does.

*where
Address &FC14E734 is at offset &0000F074 in module 'SharedCLibrary'
*

It seems to be a first time around thing here, a second run works.

edit The bug is that Obey$Dir is used in the main program, this is set in !Run but is reset if the TaskWindow provider starts up. The fix is to use an application specific variable such as WAV_Gen$Dir and rebuild. That works here, tested on a low vector Titanium. (There is pain in high vector mode.)

Interesting. I’ve not had anyone report this before and it hadn’t occurred to me. I always have a TaskWindow provider running by default and have tended to take for granted others will as well. I guess this means pretty much all my apps will hit the same problem if the user doesn’t have a provider running? If so, I guess modifying this should be on my to-do list.

WRT to the ‘pain’. Does that also mean my apps will need me to get a ROOL compiler update and recompile my programs?

IIRC someone said something similar about my !DrawGen which uses ABC, but I’ve not got the updated ABC yet. I assume I should set aside some time to do these updates.

BTW !WAV_Gen only is for generating test tones. Sine/Square/etc. It isn’t an editor like Audacity.

Jim

WRT to the ‘pain’. Does that also mean my apps will need me to get a ROOL compiler update and recompile my programs?

No, it shouldn’t. I think that the new compiler avoids using the ARM instructions that are problematical.
Most pains are cause by progamming errors.

Also I’d avoid getting a DDE update for a while until it’s been fully pain fixed.

WRT to the ‘pain’. Does that also mean my apps will need me to get a ROOL compiler update and recompile my programs?

As Jeff said most of the zeropain events are caused by programmer errors so the first pass would be to run the software on a zeropain enabled system and collect the error log text then change those bits in the source and recompile (on a non-zeropain enabled system as the compiler may have “issues”¹

¹ which of course ROOL will² be fixing in the next release.
² Hopefully

Mmm… Forum threw away my message and asked me to log in again for no explicable reason. Luckily I had prescience and ^A ^C’d it. :-)
Browser: NetSurf 3.5

IIRC someone said something similar about my !DrawGen which uses ABC, but I’ve not got the updated ABC yet.

Don’t feel bad. I have DDE26 (the most recent version) and that comes with ABCLib 4.15 (and the one within the !ABC app is even older – 4.14).
I believe we’re up to 4.17beta…but where is it?

WRT to the ‘pain’. Does that also mean my apps will need me to get a ROOL compiler update and recompile my programs?

I would love to say “the compiler sucks and is rather broken”, but unfortunately I can’t. I think the compiler generates pain. I don’t remember as I built myself a low-vectors version of RISC OS for day to day use. Thing is, if the compiler makes stray accesses to zero page, it’s done so for over a quarter of a century and the resultant programs have worked.

You are five-nines likely to find that pain encountered will be due to your own errors – especially since RISC OS is a lot less tolerant to errant stuff now (any ZP access will generate pain, so times when you might have just passed a NULL around…).

Some examples from my Codey McCodeFace experiences:

• Passing NULL to MessageTrans/OS_WhatEver when it would usually expect to have some input will now blow up in your face the moment the recipient attempts to access whatever the NULL would have been.

• People that try to be clever and test a value for “being something” and “being NULL” in the same big conditional if will come unstuck, as the compiler most likely will be resolving the contents of the pointed-to address during the checking (and then later disregarding it if the value was NULL anyway). This turned up a few times in Ovation. What you’ll need to do is see if the value is NULL in an outer if statement, and then look at what it is only if it is not NULL.

• CLib really doesn’t like you using stale file handles by mistake. Best case scenario, you’ll get pain. Worst case you’ll stiff the entire machine. The way feof() is implemented is…interesting.

• Of course there’s the ever-ready-to-bite “create a pointer, use the pointer, realise you perhaps should have pointed the pointer at something first…”.

• It is common practice to get a NULL back from error-returning routines if there was no error to return (DeskLib does this a lot). Check carefully how you handle this reply to make sure there is no possibility that you’re doing anything other than checking NULL equivalence before knowing whether or not it is ‘safe’ to look at the error data.
  Yes, this is basically a repeat of the second bullet point. This is because I’ve come across code such as the following, to report an error unless it is some specific error number:

   e = some_os_call(param, param, param);
   if (e != NULL) & (e.errnum != 1234)
   {
      complain a lot;
   }

• Pointers in C in general are a snakes pit of wriggly things with teeth. If you trace back some pain to a bunch of pointer code, break open a bottle – you’ll need it.

There is pain

I have had another look at my locally ‘fixed’ !WAV_Gen on high vector platforms, RPi3 and Titanium. There is a crash, with pain, if the path specified in !WAV_Gen.Path does not exist on the host machine. That needs to be set to something sensible before running !WAV_Gen. Once that is out of the way the new version looks to be pain free.

CLib really doesn’t like you using stale file handles by mistake. Best case scenario, you’ll get pain.

I think something like that was the issue here. Not stale perhaps, just not there at all.

The neat way to fix this is for Jim to modify the !run file to SET WavGenDir to Obey$Dir and then call the Wav_GenDir RunImage and the source to create an output directory locally if one doesn’t exist. (The path file is a bit of a Windows.INI file style of thing)

The quick and dirty method for those not wanting to modify the source and recompile is to modify the Run file:

WimpSlot -min 1536k
Set Wav_GenDir < Obey$Dir >
CDir < Wav_GenDir >.^.wav_out
TaskWindow < Wav_GenDir >.!RunImage

< Wav_GenDir >.^.wav_out

That should cater for both of the issues highlighted by David in a quick and dirty fashion.

Fighting textile here, the spaces in the directory variables aren’t needed except to batter textile into not trying to translate the enclosed item.

Yes, when I get a round tuit I’ll modify all my apps to go via setting up a specific$Dir. I’ll make an announcement when this done.

I confess I’ve taken for granted that people will have a TaskWindow provider running. IIRC !Edit does this, and I assumed most people would have an alternative running.

Yes, when I get a round tuit I’ll modify all my apps to go via setting up a specific$Dir.

The $ isn’t required. My use of Wav_GenDir (no $) was quite deliberate. Historically there’s the odd programmer reference to the My$Dir style being more of an affectation than anything – my view is it’s one less key to hit, two if you count shift.

The CDir element was because the RunImage requires the directory to exist but doesn’t create it thereby generating a nice crash. The RunImage ought to do the creation at a point relative to the application directory, but a crowbar in the Run file achieves the same.

Yes, when I get a round tuit I’ll modify all my apps to go via setting up a specific$Dir.

The $ isn’t required. My use of Wav_GenDir (no $) was quite deliberate. Historically there’s the odd programmer reference to the My$Dir style being more of an affectation than anything – my view is it’s one less key to hit, two if you count shift.

When you register an application or module name you automatically get all system variables AppName$* / ModuleName$* allocated to you too.

So if you’re registering your program names, there’s little point in using anything other than WAV_Gen$Dir.

When you register an application or module name you automatically get all system variables AppName$* / ModuleName$* allocated to you too.

Unregistered apps?

Unregistered apps?

If you use AppName$ then you won’t have to make any changes if/when you do register (assuming there isn’t actually a name clash with another registered app)

Unregistered apps?

… should probably not be distributed, as their names could cause clashes with other (registered) applications. That I thought is the reason for the Resource allocation system?

People that try to be clever and test a value for “being something” and “being NULL” in the same big conditional if will come unstuck, as the compiler most likely will be resolving the contents of the pointed-to address during the checking (and then later disregarding it if the value was NULL anyway). This turned up a few times in Ovation. What you’ll need to do is see if the value is NULL in an outer if statement, and then look at what it is only if it is not NULL.

That’s true for BASIC, but not C. I also seem to remember David Pilling stating that the main Ovation problem was more subtle than that.

It is common practice to get a NULL back from error-returning routines if there was no error to return (DeskLib does this a lot). Check carefully how you handle this reply to make sure there is no possibility that you’re doing anything other than checking NULL equivalence before knowing whether or not it is ‘safe’ to look at the error data.

Yes, this is basically a repeat of the second bullet point. This is because I’ve come across code such as the following, to report an error unless it is some specific error number:

e = some_os_call(param, param, param);

if (e != NULL) & (e.errnum != 1234)

{

   complain a lot;

}

Again, that’s wrong – unless you’re making a subtle point about logical vs bitwise operators in C. Shouldn’t e be a pointer, too?

In C, the && and || operators use a clearly defined “short-circuit evaluation” path, which means that they are required to never do more work than they absolutely need to. As such,

e = some_os_call(param, param, param);
if ((e != NULL) && (e->errnum != 1234))
{
   complain a lot;
}

(noting the use of && instead of &) is a completely acceptable way to avoid dereferencing a NULL e: if is is NULL, the whole if() clause can’t ever be true and so the second part of the condition won’t get executed at all.

Similarly, you can do the opposite:

e = some_os_call(param, param, param);
if ((e == NULL) || (e->errnum == 1234))
{
   complain a lot;
}

because again, if e is NULL then the clause must be true and there’s no point executing the second part of the condition.

In Ovation, I have a memory of David P stating that there was code like

if ((e->errnum != 1234) && (e != NULL))

floating around in the source. That will deference a NULL e, as the expression is evaluated left to right and so the test for NULL isn’t done until after trying to see if errnum is 1234 or not. The fix should have been to just reverse the order of the conditional expressions.

Note that because BASIC doesn’t have separate logical and bitwise AND and OR operators, this neat scheme doesn’t work there. If you do

IF error% <> 0 AND !error% <> 1234 THEN ...

then both parts of the expression will always be evaluated. Hence in BASIC you must nest IF statements to be safe:

IF error% <> 0 THEN
  IF !error% <> 1234 THEN ...
ENDIF

This is one reason why I don’t have much time for BASIC these days: this kind of simple thing is so cumbersome. It is possible to do a more compact

IF error% <> 0 THEN IF !error% <> 1234 THEN ...

for single-line THEN clauses, but I’m afraid that I find that pretty ugly…

Unregistered apps?

… should probably not be distributed, as their names could cause clashes with other (registered) applications.

I was thinking about stuff that’s accessible but not exactly “finished”

1. Everyone fiddles with new stuff that may or may not be put out in the wild
2. Items of interest to others that are merely half-works probably shouldn’t clutter the resource allocation system.

I think the compiler generates pain.

Isn’t there a “don’t” missing there: ie. “I don’t think the compiler generates pain”?

Unlike – say – unaligned loads and stores, surely the compiler will simply generate code that reads from the places that the programmer tells it to?

Items of interest to others that are merely half-works probably shouldn’t clutter the resource allocation system.

Yes, well. I used to think that. As a policy, time hasn’t shown it to be a good one.

Yes, well. I used to think that. As a policy, time hasn’t shown it to be a good one.

competent programmer vs. twiddler.

Different leagues.

Again, that’s wrong – unless you’re making a subtle point about logical vs bitwise operators in C.

Apologies if you read too much into & vs &&. It was written late at night when I was tired. To give an example, look at act.setactives() in Ovation. That caused pain for exactly the reason of trying to reference a NULL pointer.

The fix should have been to just reverse the order of the conditional expressions.

A fair enough point, but given that such things have “always worked” in the past, I can imagine there could be a fair bit of this sort of thing lurking.

This is one reason why I don’t have much time for BASIC these days: this kind of simple thing is so cumbersome.

I would prefer to put my “if not null” code in a separate if wrapper. I’ve seen enough “clever” code in my time to much prefer something that is clear and very obvious; I shouldn’t have to try to figure out how the code does what it does.

I was thinking about stuff that’s accessible but not exactly “finished”.

Ah, but the important word there is accessible. I don’t think that project that you are brewing should all be registered – I’ve started lots of things that I get bored of or abandon in favour of more interesting things, so if I registered all of them it would waste a lot of other people’s time. However the moment that the software touches a third party, even for a private beta, it should be registered. It should also be registered earlier if it is a commercial program that one plans to sell, in order to ensure early on that the name is available and doesn’t clash with something already written.

I would prefer to put my “if not null” code in a separate if wrapper. I’ve seen enough “clever” code in my time to much prefer something that is clear and very obvious; I shouldn’t have to try to figure out how the code does what it does.

I don’t think it’s unreasonable to say that

if (e != NULL && e->errno != 1234)

is a fairly standard piece of code. The short-circuit evaluation of && and || in C is pushed hard in the books that I’ve read on C, precisely because it provides a neat, concise and easily-recognisable way to do precisely this test.

This is one reason why I don’t have much time for BASIC these days: this kind of simple thing is so cumbersome. It is possible to do a more compact
IF error% <> 0 THEN IF !error% <> 1234 THEN ...
for single-line THEN clauses, but I’m afraid that I find that pretty ugly…

It is not very elegant, but can be more compact by omitting some THEN s:

IF error% <> 0 IF !error% <> 1234 THEN <true> ELSE <false>

The OR version is:

IF error% = 0 IF !error% = 1234 THEN <false> ELSE <true>

You cannot extend this to multi-line IF structures, but you can use a CASE structure.

The AND would look like this:

CASE FALSE OF
WHEN error% <> 0,!error% <> 1234:<false>
OTHERWISE <true>
ENDCASE

and the OR like this:

CASE TRUE OF
WHEN  error% <> 0,!error% <> 1234:<true>
OTHERWISE <false>
ENDCASE

As with many things, if you need to do it in BASIC you can, but another language will make it simpler.

For Basalt I implemented logical functions to do this lazy evaluation:

LOGAND(error% <> 0,!error% <> 1234)
LOGOR(error% <> 0,!error% <> 1234)

These return a value after the first parameter that determines the result, without evaluating any later parameters.