Audio library for FreeBasic - Features

For other topics related to the FreeBASIC project or its community.
Juergen Kuehlwein
Posts: 284
Joined: Mar 07, 2018 13:59
Location: Germany

Re: Audio library for FreeBasic - Features

Postby Juergen Kuehlwein » Oct 19, 2019 21:01

Believe me, it works. You could do this:

Code: Select all

#macro wave(a, b...)
    wave_##a(b...)
#endmacro


which expands to different functions: wave_sine(...), wave_triangle(...), ...
So you still need your functions, but you "consume" only the word "WAVE" (and variations beginning with it). You can still have enums, variables or procedures named "sine" or "triangle", the only thing you cannot have is another #define or #macro for "sine" or "triangle".
angros47
Posts: 1631
Joined: Jun 21, 2005 19:04

Re: Audio library for FreeBasic - Features

Postby angros47 » Oct 19, 2019 21:32

Your macro would change a call to "Wave (sine, 2000)" into "Wave_sine (2000)"

Honestly, I don't see how it could reduce "consumption" of words: if instead of naming a function "SineWave", I named it "Wave_sine", what would I gain?
Juergen Kuehlwein
Posts: 284
Joined: Mar 07, 2018 13:59
Location: Germany

Re: Audio library for FreeBasic - Features

Postby Juergen Kuehlwein » Oct 19, 2019 22:33

Well, you would have the "categorizing" effect and you would only "consume" words beginning with "wave". So as a user i would know "WAVE" (and derivatives of it) is a reserved word, i should aviod using own symbols beginning with "wave".

From Mr. Swiss´ point of view this would be much easier (he would have to learn only "WAVE" as a new [forbidden] key word instead of "sinewave", trianglewave", and so on). I don´t share his point of view in this regard, but you get my point?
angros47
Posts: 1631
Joined: Jun 21, 2005 19:04

Re: Audio library for FreeBasic - Features

Postby angros47 » Oct 19, 2019 22:48

I get your point, of course. Sometimes, for that reason, in C, all functions of a library have a prefix (all functions of OpenGL, for example, start with "gl"). All the extra commands could have a _fbsfx_ prefix, for example, but they would make the code less readable, and uglier.

Also, the functions that can be fed to SOUND are not just waveforms: you can also use a modulator, or a filter, for example... the prefix "wave" would be less appropriate with them. I get your idea, but some of its implications are not the best options, in my opinion
Juergen Kuehlwein
Posts: 284
Joined: Mar 07, 2018 13:59
Location: Germany

Re: Audio library for FreeBasic - Features

Postby Juergen Kuehlwein » Oct 19, 2019 23:25

No, you shouldn´t prefix all your functions with "WAVE". The functions dealing with waveforms should be summed up with "WAVE", the functions dealing with midi should be summed up with "MIDI", the filter functions coulds be named "FILTER" and so on.

You have certain categories of functions, one "parent" function for each category, this is what i propose. I agree, prefixing is ugly
angros47
Posts: 1631
Joined: Jun 21, 2005 19:04

Re: Audio library for FreeBasic - Features

Postby angros47 » Oct 19, 2019 23:34

So, instead of having to learn only "WAVE" as a new forbidden keyword, people would have to learn WAVE, FILTER (there is only one function that works as filter), MODULATOR, MIDI .... again, with so many categories, it would not be much different from the current situation
coderJeff
Site Admin
Posts: 3184
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Audio library for FreeBasic - Features

Postby coderJeff » Oct 20, 2019 1:06

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

All of QB's gfx statements were added by default. And a few new gfx statements were added later. Even then it was noticed that global namespace pollution was going to be a problem. Include files and namespaces are a good pollution controls.
coderJeff
Site Admin
Posts: 3184
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Audio library for FreeBasic - Features

Postby coderJeff » Oct 20, 2019 1:19

Juergen Kuehlwein wrote:Believe me, it works. You could do this:

Code: Select all

#macro wave(a, b...)
    wave_##a(b...)
#endmacro



#macro names are in the global namespace and interfere with every kind of usage.

----
For naming patterns, there are several groups of existing fb functions like Screen*, Image*, File*

Regardless, putting all functions in a namespace like 'fb' or 'fb.sfx' is best to do right from the start. A 'using fb.sfx' statement let's the user drop the full qualification of functions, constants, etc. The fb namespace is reserved for fb use.
Juergen Kuehlwein
Posts: 284
Joined: Mar 07, 2018 13:59
Location: Germany

Re: Audio library for FreeBasic - Features

Postby Juergen Kuehlwein » Oct 20, 2019 10:20

@Jeff,

i understand the concept and the need of namespaces. If there were five, six, seven libraries covering the same topic, it´s a requirement - it cannot work any other way. Not everything can be in the global namespace.

On the other side when there currently is no (nothing, nada) support for a topic, why not add some basic (!) support to FB (and thus the global namespace). You could define the standards (and maybe outline the syntax), which must be met.

Then in this case we would have at least basic audio support in FreeBASIC, without the need of having to include something or to care about namespaces. In other words we would have the easiest syntax for the most basic things. If a user wants more (more sophisticated, more audio formats, whatever), he will have to accept doing more like including include files and libraries, learning the syntax of these libraries etc.

In general, i would prefer to have basic support for all topics of general interest in FB itself. Everything else must be included in order to avoid global namespace pollution - i agree. The question is, where does "basic" end and "everything else" start. Yes, there are decisions to make. But i´m not a friend of the "OMG, please don´t add anything to the global namespace" policy. If it´s justified, because there is a benefit for the majority of users - why not?


JK
VANYA
Posts: 1370
Joined: Oct 24, 2010 15:16
Location: Ярославль
Contact:

Re: Audio library for FreeBasic - Features

Postby VANYA » Oct 20, 2019 12:07

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

All of QB's gfx statements were added by default. And a few new gfx statements were added later. Even then it was noticed that global namespace pollution was going to be a problem. Include files and namespaces are a good pollution controls.


What pollution from a few dozen keywords? PureBasic have more than 1000 built-in functions, and growing , and something I haven't seen complaints about pollution!

Many remember such commands as: FileCopy , FileAttr, Now , Year, Month, Day, Hour, Minute, Second

And who without the help guide quickly remember what header file you need to connect?

Tell me , what then is the advantage of the inclusion of the sound library angros47 delivered with the compiler? I just can download library angros47 and write #include ..... If keywords will not be included in the global namespace , I see no practical benefit for users , and for you extra loss of time.
coderJeff
Site Admin
Posts: 3184
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Audio library for FreeBasic - Features

Postby coderJeff » Oct 20, 2019 13:44

Whatever I accept, someone will be disappointed. Recommendation for #include/namespace is based on years of experience with this project, input from other developers, feedback from users. I should be so lucky to examine every problem in isolation.

What does PureBasic have to say about namespaces (modules):
Modules are an easy way to isolate code part from the main code, allowing code reuse and sharing without risk of name conflict.
...
Note: modules are not mandatory in PureBasic but are recommended when building big projects. They help to build more maintainable code, even if it is slightly more verbose than module-free code.
Juergen Kuehlwein
Posts: 284
Joined: Mar 07, 2018 13:59
Location: Germany

Re: Audio library for FreeBasic - Features

Postby Juergen Kuehlwein » Oct 20, 2019 14:40

Sorry to contradict you again. The text you quoted is about writing user code,it´s not about the compiler.

Whatever I accept, someone will be disappointed

Yes, that´s a problem in general, when you are the boss :-)

Once again, i understand that too many "core" statements in a language don´t help and make things complicated. But there should be some basic support for areas of general interest, without the need of including additional stuff. The language itself should provide a basic set of statements. I´m not speaking of hundreds of statements, but depending on the area 5,10 maybe 15, maybe more. These general areas would be: I/O, graphics, numbers, math, strings, arrays, media, network (might be expanded).

Looking at arrays, strings, media and network there is next to nothing. Yes, we can have arrays, but here are no statements for doing some very basic things like sorting, searching and the like. Yes, we have strings, but except for INSTR, LEFT, RIGHT and MID there are no string processing functions (too basic in my view). Media, we have nothing, Network, we have nothing.

Next to nothing or nothing means nothing built-in. Of course there are excellent additions for these areas. But these additions are often very sophisticated and not quite easy to learn and understand. In short, it´s often overkill for a simple task. The language itself should provide enough for fulfilling a simple task.

Jeff, i know you do what you can, this is not against you! The situation as it is, is not your fault. On the contrary your effort makes things possible again. I wonder how you managed the recent release with a whole bunch of toolchains, btw. when do you sleep?

To summarize it (and i will stop telling the same over and over again) i would plead for some (limited and justified) additions to the global namespace in order to provide or improve support of FB in certain areas.


JK
coderJeff
Site Admin
Posts: 3184
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Audio library for FreeBasic - Features

Postby coderJeff » Oct 20, 2019 17:25

St_W wrote:One of the proposals that arose in the FreeBASIC Discussion December 2017 was to add a sound library to FreeBasic. The topic has been already discussed to some extent in this action thread, where several users showed interest in such a library:
https://freebasic.net/forum/viewtopic.php?f=17&t=26246
As the thread dicussed so many different aspects I though it could be a good idea to discuss a specific aspect of the design of that sound library in a new thread; this thread.


This topic is starting to wander off like the first one.

@angros47, You have a prototype implementation. It compiles and it "works". Great.

I think it would be helpful for interested people to continue to work through St_W's proposed process. The suggestions I gave are only for how I think it would fit in to fbc project and file organization so that developers are most likely to look at it.

St_W wrote:This is my proposal of a structured process for finding an appropriate sound library design:
  1. I think it could be a good start to compile a list of features the new sound library should provide from a (FreeBasic-)user perspective.
  2. Afterwards the importance of the features could be weighted, unimportant/unnecessary features could be removed, etc.
  3. As soon as a common set of features has been found, it would be easier to design an API that provides those features.
angros47
Posts: 1631
Joined: Jun 21, 2005 19:04

Re: Audio library for FreeBasic - Features

Postby angros47 » Oct 20, 2019 18:31

Designing an API is likely harder than implementing it, since any future change will break a lot of code. At first, when I published my code snippets, I was caring mostly about implementation, but now that I have designed this prototype, I see how everyone has different opinions. And of course there is no way to modify the API that could satisfy everyone, there will always be someone who won't like it. When I chose the current names, I had one main design goal: consistency with the rest of FreeBasic in general, and with the graphic library in particular.

That's the reason of the partial retrocompatibility of some commands (PLAY in particular), and it is also the reason of my choice to support only the simplest file formats (.WAV and .MID, just as the graphic library supports only .BMP), but to support them both for reading and writing.
Even the command SoundControl tried to mimic ScreenControl

For that reason, I think that the sound library should behave like the graphic library, if possible: either they both should go under the main namespace, or they both should have dedicated namespaces.
grindstone
Posts: 725
Joined: May 05, 2015 5:35
Location: Germany

Re: Audio library for FreeBasic - Features

Postby grindstone » Oct 21, 2019 17:54

@angros47: What editor do you use? I've downloaded your sfx.zip, but here in FbEdit your sources are displayed as one single line without any line breaks. The compiler seems to get along with this, but for me as a human your source code is simply unreadable :-(
Last edited by grindstone on Oct 21, 2019 18:21, edited 2 times in total.

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 6 guests