"SOUND" redesign; New "_INITAUDIO" and "_FINISHAUDIO" statements

CharlieJV · Nov 27, 2022, 10:01 PM

Details in this blog entry.

Latest version of BASIC Anywhere Machine
Latest version of the Programming Reference
Project Website

Teaser code:

_initaudio
<<include "Hz#(note$)">>
t = 5
_sndwave "square"
sound Hz#("D5"), t*2
sound Hz#("G5"), t*3

...

sound Hz#("G5"), t*3
_finishaudio
end

johnno56 · Nov 28, 2022, 05:28 PM

I tried the tune, via the 'Project Website' link, but forgot to recall the point about lowering my system's volume... At 4:10am, using ear phones, makes for an 'amazing' alarm... lol

Would I be correct in assuming that the tune could be 'shortened' by creating a simple for...next loop to 'read' each note/duration and use only one 'sound' command?

Nicely done!

J

CharlieJV · Nov 28, 2022, 05:56 PM

You certainly could.

When "composing" (fine tuning all of the notes and the length of the notes, I would find working from a bunch of data statements would make tweaking more difficult.

To handle both composing and having something more condensed, I wouldn't bother with data statements.

I'd likely create a subroutine and not get into a READ loop of DATA statements:

_initaudio
<<include "Hz#(note$)">>
t = 5
_sndwave "square"

SUB s(note$, d%) 
  sound Hz#(note$), t*d%
END SUB

s ("D5", 2)
s ("G5", 3)

...

s ("G5", 3)
_finishaudio
end

I can't see switching that over to DATA statements providing any advantage.re program size.

CharlieJV · Nov 28, 2022, 06:13 PM

Quote from: CharlieJV on Nov 28, 2022, 05:56 PMWhen "composing" (fine tuning all of the notes and the length of the notes, I would find working from a bunch of data statements would make tweaking more difficult.

There, I'm thinking of a few DATA statements with multiple notes per statement.

Just one note/duration per per DATA statement line, I'd find that easy to work with, but no more easier than condensing code lines via use of that small Subroutine.

Ultimately, I'll implement a PLAY statement, and that should make for nicely condensed code.

CharlieJV · Nov 28, 2022, 06:18 PM

Quote from: johnno56 on Nov 28, 2022, 05:28 PMI tried the tune, via the 'Project Website' link, but forgot to recall the point about lowering my system's volume... At 4:10am, using ear phones, makes for an 'amazing' alarm... lol

Of course, I immediately focused on "business items", and totally flew by the "fun" stuff.

Not fun at all. I'd like to say for myself "once bitten, twice shy", but it seems my own experiences have taught me zilch in that respect. Volume always on high over here.

Give my sympathies to yer eardrums ! Make sure to give them some extra TLC!

johnno56 · Nov 28, 2022, 06:48 PM

I only mentioned the data statements because that was how I did it in "The Dark Ages" with my then Amstrad cpc464. Gotta love the old 8 bit machines...

I noticed that you used "square" wave... Would I be correct in assuming that, if there is one type of wave, logic would dictate that there may be others? (unless, of course, there is only 'square'... lol)

CharlieJV · Nov 28, 2022, 10:34 PM

Quote from: johnno56 on Nov 28, 2022, 06:48 PMI only mentioned the data statements because that was how I did it in "The Dark Ages" with my then Amstrad cpc464. Gotta love the old 8 bit machines...

I noticed that you used "square" wave... Would I be correct in assuming that, if there is one type of wave, logic would dictate that there may be others? (unless, of course, there is only 'square'... lol)

I like logical. In this case, how lucky: it is done rather than just a TODO.

Lookup the _SNDWAVE statement in the programming reference, or just view that "wiki-style": click here.

CharlieJV · Nov 28, 2022, 10:37 PM

And a demo of the waveforms ( programs out of date because I've since changed the SOUND statement to be asynchronous, but otherwise the sounds haven't changed):

johnno56 · Nov 28, 2022, 11:02 PM

Cool... Those sounds bring back memories... Thank you.

News:

"SOUND" redesign; New "_INITAUDIO" and "_FINISHAUDIO" statements