Audio library for FreeBasic - Features

[coderJeff]

Ok, after a long time, I finally managed to have a prototype of what I had in mind:

https://sourceforge.net/projects/freeba ... ary/files/.

Looks like a good start. Do you have specific name/email that we can use to attach to a commit?

I like the simple interface, and the design choices to limit the feature set. That's the approach I would take also; get the essentials working well. Besides, for an advanced sound library, there is already Joshy's fbsound library. Nice that it is written in fairly plain fb, but using some of the relatively newer features like extending objects. I am very interested to see the long term results of adding a new functionality to fb this way.

Perhaps, there should there be a multi-threaded version too? Where locks are held whenever accessing any shared / global resources.

Next step would be to compose the initial commit to fbc/master, putting the source files in expected locations:
./src/sfx/*.bas
./src/sfx/*.bi (the libraries private includes)
./src/sfx/<target> (target specific sources)
./inc/fbsfx.bi (the public library interface for the user)
./lib/<target> (binaries)

And then updating ./makefile to build the library automatically, or at least provide a recipe for it.

Sometime later, for QB compatibility would be nice to see a SOUND freq, duration overload, possibly even having some help from the compiler to automatically initialize the sound library if program is compiled in #lang "qb". But, for the fb dialect, requiring the #include is a good choice in my opinion.

[VANYA]

But, for the fb dialect, requiring the #include is a good choice in my opinion.

coderJeff!

And why make additional inclusions in the form of "# Include"? Why can not you make direct use of sound commands like in gfxlib?

And yes, I am very glad that you as a developer, finally paid attention to the introduction of sound in the capabilities of the compiler.

[badidea]

And why make additional inclusions in the form of "# Include"? Why can not you make direct use of sound commands like in gfxlib?

I can think of 2 reasons (but I could be wrong):
- To prevent breaking someone's code (if a have a different e.g. soundSet() in a project this gives a conflict).
- To reduce compile time and executable size when no sound is needed.
But for "QB" maximum compatibility is wanted.

[angros47]

Looks like a good start. Do you have specific name/email that we can use to attach to a commit?

You can use the email I use in this forum: angros47 at gmail.com
My name is Angelo Rosina.

I like the simple interface, and the design choices to limit the feature set. That's the approach I would take also; get the essentials working well. Besides, for an advanced sound library, there is already Joshy's fbsound library.

I can also try to put something together for 3D audio, to use it with OpenB3D. It will be a separate library, like OpenB3D is separate from the FB graphic library.

Perhaps, there should there be a multi-threaded version too? Where locks are held whenever accessing any shared / global resources.

The library at the moment is partially multi-threaded, since some features, like the midi sequencer, and, in the linux version, the midi FM synthesizer (used as fallback if no midi synthesizer is found), run in separate threads. Of course, in DOS the midi sequencer uses an ISR timer instead of a thread, so it can work even on DosBox (DOS threaded programs don't work in DosBox, I don't know why)

Since the only real shared variables that are used are the settings of the sound mode, perhaps the only change to do for a multi-threaded version would be to add some semaphores on the command PLAY and SOUND, to ensure that if they are called while another thread is already calling them, they must wait.

And then updating ./makefile to build the library automatically, or at least provide a recipe for it.

Specific batch files are already included (buildlinux.sh, buildwindows.bat and builddos.bat) , so the makefile would just have to call them

Sometime later, for QB compatibility would be nice to see a SOUND freq, duration overload, possibly even having some help from the compiler to automatically initialize the sound library if program is compiled in #lang "qb". But, for the fb dialect, requiring the #include is a good choice in my opinion.

I wonder if the include should be required, or optional (as it is for the graphic library... it would be consistent). The SOUND freq, duration can be made by remapping the SOUND command to SOUND PulseWave(freq), duration . That would be very simple to achieve, but would also introduce a less versatile syntax, and the overload would be a potential source of troubles, if someone wants to use a variable in place of the frequency value (especially since in fblite and QB mode there is no need to declare the variable type): so, the old syntax should be used only in QB mode (and in that mode, the new syntax should be __SOUND or something like that)

[MrSwiss]

I wonder if the include should be required, or optional ...

It should definitely be mandatory, because there are people (like me) who don't want any
of it as well, as the associated overhead it creates.

This is so: thanks to "Super Mario Brothers" whose sound nearly drove me "around the bend".

[angros47]

Like the graphic library, it would not be included if no command from it is used, so there would be no overhead.

Also, if anyone had a different version of SoundSet, they could always use #undef to disable that keyword. Anyway, I don't know how to add keywords to the compiler, so for that part I leave the decision to the developers who know how to do it

[MrSwiss]

... it would not be included if no command from it is used ...

This is nonsense because it would mean, that I have to learn those keywords, I don't
ever intend to use anyway (just to avoid them).
Those wanting to use it, should have the work (not the other way around).

I wouldn't want those keywords in 'global namespace' anyway (as a second reason).

[angros47]

If you don't intend to use the sound feature it's very unlikely that your program will contain keywords named SOUND, PLAY, SineWave and so on, so you will have no need to change anything, even if the library were enabled.

[MrSwiss]

... it's very unlikely that your program will contain keywords named SOUND, PLAY, SineWave and so on, ...

That is the point where you are wrong, I've at least one program that contains a
procedure named SineWave(), but for drawing it, nothing to do with sound.

Just assuming things is likely, to end up in desaster ...

[speedfixer]

As with the graphics library, when some keywords are used the extra linking is triggered, but the use of some of the features of graphics will still throw an error when used without some of those keywords or the #include for graphics. No one wants to be required to use #include in most of these cases.

Perhaps the most basic, obvious, (historical ?) keywords would be the trigger, and more obscure, or less sound-lib specific keywords would just throw an error if not defined --- and could then be used by a user library/function.

The use of:

SOUND is very clear.
PLAY - historical - but maybe able to be overloaded.
SINEWAVE - only valid if defined - by use of the FB sound lib or defined by the user.

I don't like ANY bloat, but sound is kind of expected in what is supposed to be a super-user friendly language like any BASIC should aspire to be these days.

Same approach needs to be taken with fonts in the graphics screens. I'm old: my eyes are weak. My 4k screen makes life a little easier - until I run an FB program.

david

[MrSwiss]

As with the graphics library, ...

There you already have it: it isn't like the graphics library. (which is in FB for a long time)
AFAIK: to trigger gfx-lib loading, there are only two KeyWords: Screen/ScreenRes

Instead of defining umpteen new KeyWords (to load a new lib/feature) a single #Include
statement, isn't asked to much, IMO. Especially, if it eliminates probable problems, before
they get a chance to manifest themselfs.

[angros47]

The trigger keyword, in this case, would likely be SoundSet and SoundMidiSet

[speedfixer]

FB hasn't changed changed in the time that I have been with it. Not long, just 7 years.

Sure: 64 bit, a LOT of fixed bugs.
A very few features, actually. Sure, more RTTI and c++ like objects, but those are sugar and icing: There really isn't anything NEW that can be done now that couldn't be done before. (Folks, that isn't a challenge.)

FB is powerful. But:

To write ANY useful app beyond a simple tool - some other library has to be brought in to complete the picture.

Sound.
Fonts.
Network.
Big, fast data.
Interprocess communications.
Media presentation.
Any gui.

The list goes on.

BASIC is NOT a low level language.
FB is way more powerful than most BASICs.

But you can't call FB a *modern* high level language without some of those features.

Integral sound would be one of the steps needed to do that without just seeming to add another lib by requiring another #include to make it work.

A thought of mine:

Everyone that writes their own BIG programs has their own way of bringing in all these features.
So when talk of bringing these features into FB come around, those guys just sit in the back and watch a few spirited people bash each other over their favorites.

So we have ten ways to do everything. Cool. Flexible.
Totally fragmented from an outsider's point of view.
Too many things to learn from a beginner's point of view.

Can't just simply play a tune or see a picture or load some data without a *lot* of work and MORE than just FB to learn.

As long as these things aren't folded directly into FB, it will always just be seen as a toy language: not good for any one purpose but to 'play' at programming.

Any three of the above would make a HUGE difference in the perception of FB.
There are more than one very good libs for each of those topics above that could be brought into FB rather quickly.

AND you could still use something else if you wanted to.


FOR THIS TOPIC (audio), we need more input from others to persuade the devs.
Or the devs can just do it the way they wish.

david

[Juergen Kuehlwein]

angros47,


you could reduce the number of new key words needed by changing your syntax a bit.
Example:
instead of sinewave, trianglewave, ..., syncwave, mixwaves, loadwave, playwave, savewave"
use wave(sine|triangle|...|sync|mix|load|play|save, ...).

This requires only one new word ("WAVE") instead of a lot of others. The first word tells the user what´s it all about: WAVE, and the following specifies what to do with it and how. You could group all other names in a similar way.

This more hierachical approch limits the amount of new words needed and makes the whole thing easier to understand, because the syntax already categorizes it for the user. That´s what i did with my array features. You will need to wrap your functions with a macro to do this.


JK

[angros47]

You are right, but the different waveforms require different parameters: SineWave, TriangleWave and SawToothWave require only a frequency, while PulseWave requires an (optional) duty cycle parameter, NoiseWave requires no parameters at all, and HarmonicWave allows to specify the intensity of up to ten harmonics.

Also, to specify the waveform (sine|triangle.... and so on), I could represent it with a number, but it wouldn't be very user friendly (would you like to have to remember that the noise is 5, for example?). So I would need an ENUM with the list of wave type, and I would still need to use different symbols.