Part 3: Action (hopefully)

[Imortis]

One of the things that struck me from coderJeff's Community Discussion topic is that a lot of ideas I would have previously discarded now seem a bit more reasonable to me.

A good example is the idea of an embedded sound library in freeBASIC. I was previously in the camp of "don't add features that a library could do", but with more and more languages having easy access to such a thing, that answer is wearing a bit thin.

I would like to propose this: assuming D.J. Peters can be reached for comment, Let us update FBSound to be 64bit friendly and include it in FB the same way FBGfx2 is, under the FB namespace. We could even break it out into FB.Sound.

The library works really well and, aside from a bit of the asm in it, would be pretty easy to make multi-platform.

And if we do that, why not move all FBGfx command to FB.GFX? And RTLib to FB? We could greatly clean up the namespace and make more variable and function names available to the coder.

Code could be written in a macro to include the "Using FB" when on new versions of the compiler, just like we do for FBGfx.

I am willing to help out/get started on all of this, if the community likes the idea.

[St_W]

[..]Let us update FBSound to be 64bit friendly and include it in FB the same way FBGfx2 is, under the FB namespace. [...] The library works really well and, aside from a bit of the asm in it, would be pretty easy to make multi-platform.

I've rewritten large parts of the asm code in FreeBasic a while ago, but porting the FBSound library to other systems or 64-bit really requires quite some effort. Additionally it depends on multiple C libraries which are, similar to FBSound, not updated anymore by its authors. And another reason to not use FBSound is its unclear license and the licenses of the C libraries used. On the other hand I agree that FBSound works well, provides a lot of features and would definitly be an improvement for FB. Yet I think that FBSound is not really suitable here and we need something more lightweight, that depends on common system libraries only, similar to FBGfx.

And if we do that, why not move all FBGfx command to FB.GFX? And RTLib to FB? We could greatly clean up the namespace and make more variable and function names available to the coder. Code could be written in a macro to include the "Using FB" when on new versions of the compiler, just like we do for FBGfx.

I suggested that some years ago, but I guess it doesn't match the programming style of many FB users, which resembles the programming style of the 80s rather than current standards (which is not bad per se). The only chance for such a big change would probably a new language mode (in addition to qb, fblite and fb), but I don't really like that.

[badidea]

I'm not an expert on how to include it in the compiler or in the FB distribution, but working sound 'out of the box' (on windows and linux, with example code) would be great, especially for game development.

The last time I used FBsound was in 2012. When I try to compile it now, the linker cannot find the correct libraries although I do have them installed, but maybe the wrong version or at wrong location. If a spend an evening on it, I'll probably get it working (one one machine), but I don't want to spend time fiddling with libraries after every OS update or new computer. It's like 30 years ago when you had to tell your computer which Sound Blaster card you had and which IRQ it to use, etc. Annoying.

So, sound, yes please. I am, however, not sure if I can help, due to limited time and knowledge. Maybe testing :-)

[paul doe]

I am willing to help out/get started on all of this, if the community likes the idea.

I like the idea. I have other ideas too, but I don't want to discuss them here in the open. Any chance we can get in touch?

[angros47]

I, too, agree that FreeBasic should have some sound commands. But I think FBSound has some issue, about that: in fact, it requires some external files (the plug-in dynamic libraries), and this breaks the ability to build stand-alone executables. Also, it does not follow the same "philosophy" of the graphic library: in fact, it is designed to load and play .WAV, .MP3 and .OGG files, and it works perfectly... but it lacks features to play a specific frequency, or produce a specific wave form. There is nothing equivalent to the old SOUND and PLAY commands, that were very limited, but more versatile and immediate. To address the problem, it would be like having a graphic library that can load not just .BMP, but also .PNG and .JPG pictures... but lacking commands like PSET, LINE, CIRCLE and so on. This would not be Basic any more, and such a library should not be part of the main language.

I'd suggest that a sound library should support only .WAV files (other formats could be accessed with external loaders), but it should provide low level access to audio buffer data, and perhaps provide commands to build complex sounds from scratch. I made some tests on that subjects in the last years, and I also managed to control audio output under Windows, Linux and DOS, without using any assembly part.

[St_W]

Also, it does not follow the same "philosophy" of the graphic library: in fact, it is designed to load and play .WAV, .MP3 and .OGG files, and it works perfectly... but it lacks features to play a specific frequency, or produce a specific wave form. There is nothing equivalent to the old SOUND and PLAY commands, that were very limited, but more versatile and immediate. To address the problem, it would be like having a graphic library that can load not just .BMP, but also .PNG and .JPG pictures... but lacking commands like PSET, LINE, CIRCLE and so on. This would not be Basic any more, and such a library should not be part of the main language.

I'd suggest that a sound library should support only .WAV files (other formats could be accessed with external loaders), but it should provide low level access to audio buffer data, and perhaps provide commands to build complex sounds from scratch. I made some tests on that subjects in the last years, and I also managed to control audio output under Windows, Linux and DOS, without using any assembly part.

I do not think that the BASIC philisophy is about providing low level access to system resources, which is hard to use in practice. Rather than that BASIC aimed to provide high level features that are easy to use. You seem to miss the fact that e.g. drawing lines, circles or playing music (PLAY command) were high level commands at the time BASIC was popular, in the 1980s/90s. Nowadays I'd consider the inclusion of loaders for OGG, PNG or JPG would perfectly follow the philosophy of BASIC. Some beep tones were the default sound option on an x86 PC (if you didn't buy any SoundBlaster card or similar) . Nowadays playing an MP3 file is such a basic operation that is supported on practically every PC.

[Imortis]

I am willing to help out/get started on all of this, if the community likes the idea.

I like the idea. I have other ideas too, but I don't want to discuss them here in the open. Any chance we can get in touch?

Sure. ImortisInglorian@gmail.com for email or hangouts. I am also on Discord as ImortisInglorian#1010

[Imortis]

Also, it does not follow the same "philosophy" of the graphic library: in fact, it is designed to load and play .WAV, .MP3 and .OGG files, and it works perfectly... but it lacks features to play a specific frequency, or produce a specific wave form. There is nothing equivalent to the old SOUND and PLAY commands, that were very limited, but more versatile and immediate. To address the problem, it would be like having a graphic library that can load not just .BMP, but also .PNG and .JPG pictures... but lacking commands like PSET, LINE, CIRCLE and so on. This would not be Basic any more, and such a library should not be part of the main language.

I'd suggest that a sound library should support only .WAV files (other formats could be accessed with external loaders), but it should provide low level access to audio buffer data, and perhaps provide commands to build complex sounds from scratch. I made some tests on that subjects in the last years, and I also managed to control audio output under Windows, Linux and DOS, without using any assembly part.

I do not think that the BASIC philisophy is about providing low level access to system resources, which is hard to use in practice. Rather than that BASIC aimed to provide high level features that are easy to use. You seem to miss the fact that e.g. drawing lines, circles or playing music (PLAY command) were high level commands at the time BASIC was popular, in the 1980s/90s. Nowadays I'd consider the inclusion of loaders for OGG, PNG or JPG would perfectly follow the philosophy of BASIC. Some beep tones were the default sound option on an x86 PC (if you didn't buy any SoundBlaster card or similar) . Nowadays playing an MP3 file is such a basic operation that is supported on practically every PC.

I think you both have good points. I think making something with no dependencies outside of OS specific stuff is good. I also think that higher level things like loading OGG is also good.

@angros47: Did you put your results on the forum anywhere? I would like to see what you have and try to learn from it.

[paul doe]

Sure. ImortisInglorian@gmail.com for email or hangouts. I am also on Discord as ImortisInglorian#1010

Nice, thanks! Sent you an email.

[angros47]

I do not think that the BASIC philisophy is about providing low level access to system resources, which is hard to use in practice. Rather than that BASIC aimed to provide high level features that are easy to use. You seem to miss the fact that e.g. drawing lines, circles or playing music (PLAY command) were high level commands at the time BASIC was popular, in the 1980s/90s. Nowadays I'd consider the inclusion of loaders for OGG, PNG or JPG would perfectly follow the philosophy of BASIC. Some beep tones were the default sound option on an x86 PC (if you didn't buy any SoundBlaster card or similar) . Nowadays playing an MP3 file is such a basic operation that is supported on practically every PC.

A programming language must provide tools, not pre-made solutions: when I first try Visual Basic (still on Windows 3.1), for example, I was excited to see how easy it was to load and play .WAV files... but my excitement was replaced by disappointment, when I realized that there was no way to play custom sounds, the only way to play different sounds was to have different wave files. So, even doing a simple piano keyboard (something that, with SOUND command, was easy to do even on older home computers) was impossible.

Consider how a command can be used, in a program you are writing: with SOUND and PLAY, a simple music could be done. Or a piano keyboard could be written. Or you could try to procedurally create sound effects and music, and see the different effects. Some people even managed to produce speech synthesis using just the SOUND command. It is versatile... in the limits of the available hardware, of course.

With a command to reproduce MP3, you can make a sound player (as if there weren't enough of them). You can play the background music in a video game. Or you can play a pre-recorded message. Nothing more. A simple web page can do the same. A real sound library should do more than that: it should allow to create customized sound effects; to play a specific musical note, or sequence of notes. Perhaps even to synthesize speech. Similar features would be versatile.

And about the ability to control the low level access, feeding raw data, it would be nothing more than what ScreenPtr already does for graphics.

I think you both have good points. I think making something with no dependencies outside of OS specific stuff is good. I also think that higher level things like loading OGG is also good.

@angros47: Did you put your results on the forum anywhere? I would like to see what you have and try to learn from it.

https://freebasic.net/forum/viewtopic.p ... 7&p=203957 Different wave forms

https://freebasic.net/forum/viewtopic.p ... 9&p=236298 Audio for windows (no external libraries needed, no asm used, can be ported on 64 bit)

https://freebasic.net/forum/viewtopic.php?f=5&t=23122 Audio for Linux (both Alsa and OSS are supported)

https://freebasic.net/forum/viewtopic.php?f=4&t=23123 Audio for DOS (Yes, DOS is supposed to be supported, since FreeBasic is available for DOS)

https://freebasic.net/forum/viewtopic.php?f=8&t=22001 Midi synthesizer using FM (for Linux, if you have no hardware and you don't want to install Timidity and the huge sound fonts)

https://freebasic.net/forum/viewtopic.p ... 1&p=192612 Midi for Linux

https://freebasic.net/forum/viewtopic.p ... 4&p=202741 Midi for DOS (works in DosBox)

https://freebasic.net/forum/viewtopic.p ... 1&p=230961 Speech synthesis for DOS

Is it enough, to start building a new sound library for FreeBasic?

[St_W]

A programming language must provide tools, not pre-made solutions: when I first try Visual Basic (still on Windows 3.1), for example, I was excited to see how easy it was to load and play .WAV files... but my excitement was replaced by disappointment, when I realized that there was no way to play custom sounds, the only way to play different sounds was to have different wave files. So, even doing a simple piano keyboard (something that, with SOUND command, was easy to do even on older home computers) was impossible.

Have a look at popular programming languages (e.g. C#, Java, Python, ...) they usually come with a whole lot of pre-made solutions in their own standard-library, containing ready-to-use implementations for common data structures (lists, maps, sets), network, image, sound, GUI implementations ... and many more features. Of course these libraries are not directly part of the language (and I wouldn't like to see that in FB either, as we have already too many keywords) but they are part of the compiler/development package. e.g. there is no Java without the Java Class Library usually.
And of course those pre-made solutions won't fit in every situation, only in the most common ones. But in such cases you are still free to implement your own solution, just like you could have implemented your own custom sound or play command in VisualBasic if you wanted to do so.

Consider how a command can be used, in a program you are writing: with SOUND and PLAY, a simple music could be done. Or a piano keyboard could be written. Or you could try to procedurally create sound effects and music, and see the different effects. Some people even managed to produce speech synthesis using just the SOUND command. It is versatile... in the limits of the available hardware, of course.

Even back in the DOS days the hardware wasn't the limiting factor as many programs showed, which got impressive results from the PC beeper; something that couldn't have been implemented with (Quick)Basics's PLAY or SOUND commands. Nowadays PLAY and SOUND would provide an even more limited result of what current sound hardware could do. Yet I agree that these commands still make sense for some very basic sound output. But I'd say that playing simple WAV/MP3/OGG files is at least as commonly used today. As I've written above, the standard library (rtlib/gfxlib in FB) should provide commonly used features. If you need more, again, you're free to implement your own sound output or use an existing library like FBSound.

With a command to reproduce MP3, you can make a sound player (as if there weren't enough of them). You can play the background music in a video game. Or you can play a pre-recorded message. Nothing more. A simple web page can do the same. A real sound library should do more than that: it should allow to create customized sound effects; to play a specific musical note, or sequence of notes. Perhaps even to synthesize speech. Similar features would be versatile.

Quite a lot of commonly needed features can be realized with a simple sound player. For example the PLAY command can be implemented by providing samples for all needed different notes.

And about the ability to control the low level access, feeding raw data, it would be nothing more than what ScreenPtr already does for graphics.

I didn't say that I don't like low level access, I just wanted to mention that it hasn't been the original philosophy of BASIC to do a lot of bit-twiddling, pointer-magic or direct hardware access. Of course people had to resort to those possibilities (as far as BASIC allowed) when the pre-made solutions of BASIC did not fit their needs anymore (maybe you remember DirectQB?).

____

Your code is definitely a good start, but we have to think about which audio features are commonly needed and should be exposed to the FreeBasic user in a simple way while still allowing as much flexibility as possible. Low-level access can be provided for more experienced users, but most users of FB probably want something simple (but still powerful). This would probably include the PLAY or SOUND commands as known from QB, but also additional features to load, (modify?) and play Wave/MP3/OGG files.

Designing a good API at least as important as important as a good implementation.

[angros47]

Have a look at popular programming languages (e.g. C#, Java, Python, ...) they usually come with a whole lot of pre-made solutions in their own standard-library, containing ready-to-use implementations for common data structures (lists, maps, sets), network, image, sound, GUI implementations ... and many more features. Of course these libraries are not directly part of the language (and I wouldn't like to see that in FB either, as we have already too many keywords) but they are part of the compiler/development package.

That's the point: in Basic, the graphic commands are part of the core language. And the same should apply for sound commands. The graphic commands allow low level access to the page, and offer some primitives. They don't provide pre-made solutions. If you want a loader for .JPG or .PNG, you can use an external library. The same should apply for sound: the core language should offer sound primitives, while the support to .MP3 or .OGG file should be external

Even back in the DOS days the hardware wasn't the limiting factor as many programs showed, which got impressive results from the PC beeper; something that couldn't have been implemented with (Quick)Basics's PLAY or SOUND commands. Nowadays PLAY and SOUND would provide an even more limited result of what current sound hardware could do.

In fact I am talking about providing something more advanced: wave generators (triangle, pulse, sine, sawtooth), filters (low pass, high pass, band pass, notch), modulators (amplitude, frequency, ring, phase), envelope generators (ADSR) and so on

Quite a lot of commonly needed features can be realized with a simple sound player. For example the PLAY command can be implemented by providing samples for all needed different notes.

That is exactly what I want to avoid: because it would promote horribly inefficient solutions: providing a sample for every note would need huge sound fonts, that could contain hundreds of variants of the same sound... just to play a simple tune. Does it make sense to use a 50 mb download for something that in the past was achieved with a 30kb program.

I didn't say that I don't like low level access, I just wanted to mention that it hasn't been the original philosophy of BASIC to do a lot of bit-twiddling, pointer-magic or direct hardware access. Of course people had to resort to those possibilities (as far as BASIC allowed) when the pre-made solutions of BASIC did not fit their needs anymore (maybe you remember DirectQB?).

I remember DirectQB... a library written by the same person who lately wrote the Freebasic graphic library.

Your code is definitely a good start, but we have to think about which audio features are commonly needed and should be exposed to the FreeBasic user in a simple way while still allowing as much flexibility as possible. Low-level access can be provided for more experienced users, but most users of FB probably want something simple (but still powerful). This would probably include the PLAY or SOUND commands as known from QB, but also additional features to load, (modify?) and play Wave/MP3/OGG files.

Designing a good API at least as important as important as a good implementation.

A starting point would be having a common, device-independent environment to send raw data (the equivalent of having just SCREENSET and ScreenPtr: not the best, but you can already code graphic). Then, a set of primitives can be built on it. For the QB mode, PLAY and SOUND would be all we need, for FreeBasic more advanced primitives can be added. But I have a question for you: would you prefer a graphic library that can load .JPG and .PNG files, but lacking all the primitives like LINE, CIRCLE and so on, or the current situation?

[marcov]

That's the point: in Basic, the graphic commands are part of the core language.

There are multiple directions to go with drawing. Directly on a canvas, via a widget set, or via opengl/directx/vulkan. And of course plain sad old framebuffer and even older VESA 1.x VGA.

Which one to chose? The one with the most future potential, Vulkan ?

That is exactly what I want to avoid: because it would promote horribly inefficient solutions: providing a sample for every note would need huge sound fonts, that could contain hundreds of variants of the same sound... just to play a simple tune. Does it make sense to use a 50 mb download for something that in the past was achieved with a 30kb program.

If you can generate it to play directly, you can generate it on install or first run too. No downloads and no hardware or API dependent mess.

I didn't say that I don't like low level access, I just wanted to mention that it hasn't been the original philosophy of BASIC to do a lot of bit-twiddling, pointer-magic or direct hardware access. Of course people had to resort to those possibilities (as far as BASIC allowed) when the pre-made solutions of BASIC did not fit their needs anymore (maybe you remember DirectQB?).

I think you are more of a QB64 person. Emulations seem to suit you.

[jj2007]

Consider how a command can be used, in a program you are writing: with SOUND and PLAY, a simple music could be done. Or a piano keyboard could be written. Or you could try to procedurally create sound effects and music, and see the different effects. Some people even managed to produce speech synthesis using just the SOUND command. It is versatile... in the limits of the available hardware, of course.

With a command to reproduce MP3, you can make a sound player (as if there weren't enough of them). You can play the background music in a video game. Or you can play a pre-recorded message. Nothing more. A simple web page can do the same. A real sound library should do more than that: it should allow to create customized sound effects; to play a specific musical note, or sequence of notes. Perhaps even to synthesize speech. Similar features would be versatile.

Syntax-wise, something like this?

Code: Select all

            Sound "880:200"              ; plays frequency 880Hz for 200 ms; allowed separators are space, tab, / and :
            Sound "880/200/150"          ; plays frequency 880Hz for 200 ms, followed by 150 ms of silence
            Sound 111                    ; plays a wav resource with ID 111 (in rc file: 111 WAVE "hello.wav")
            Sound "hello.wav"            ; plays a file directly (wav only)
            Sound "hello.mp3"            ; plays a file in its associated player
            Sound "大桥在混乱的水.mp3"     ; Unicode names are allowed
            Sound Utf8$(wCL$())          ; even if passed via the commandline
Rem         - The simple "frequency:duration" syntax works on Windows 7 and higher but not on Windows Vista;
              a minimum duration of about 90...100 ms is required
            - PlaySound/Beep/ShellExecute results can be checked with Err$()

[VANYA]

The sound in freebasic is necessary surely. In principle, if there is an opportunity to fasten fbsound, then this best decision. However I think that there will be many problems with a binding to the compiler, especially with the version 64x-bit. From other party it will be quite good if there is even only one WAV format. I wrote a code which works at LINUX 32\64, WINDOWS 32\64 and you can use this code for the compiler if you want. Code here: https://freebasic.net/forum/viewtopic.php?f=8&t=25841