Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2014-01

fp universal library ?

36 messages · 11 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Fred van Stappen

Hello everybody ;-)

I have developed a fp-wrapper, uos, who links to the best audio open-source libraries:

This main fp-wrapper uses other fp-wrappers who link to those audio-libraries. Those fp-audio-wrappers have much more features than the c original audio-wrappers (dynamic loading, reference counters,...).

Now the questions:

1) Is it possible to create a library from main fp-uos wrapper (including audio-libraries fp-wrappers, not the audio-libraries them-self) ?

2) If 1) = true, could you give me some advice how to do it ?

3) May that fp-uos library be accessible for other languages (C, java,...) ?

4) If 3) = true, what is the best way to create foreign-wrappers to that fp-uos-library (wrappers for C, java,...) ?

Many thanks.

leledumbo
to Fred van Stappen
1) Is it possible to create a library from main fp-uos wrapper (including

audio-libraries fp-wrappers, not the audio-libraries them-self) ?

Sure

2) If 1) = true, could you give me some advice how to do it ?

Err...read the documentation about how to write a (dynamic) library?

3) May that fp-uos library be accessible for other languages (C, java,...) ?

Yes

4) If 3) = true, what is the best way to create foreign-wrappers to that fp-uos-library (wrappers for C, java,...) ?

Provide procedural interface with common calling convention, cdecl and stdcall AFAIK are the most supported calling convention, almost (if not) every compiler understands them

View this message in context: http://free-pascal-general.1045716.n5.nabble.com/fp-universal-library-tp5718166p5718169.html Sent from the Free Pascal - General mailing list .
Paul Breneman
to Fred van Stappen: Hello everybody ;-) I have developed a fp-wrapper, uos, who links to the best audio…
Fred van Stappen wrote 20 lines
Hello everybody ;-) I have developed a fp-wrapper, uos, who links to the best audio open-source libraries: >> https://github.com/fredvs/uos/ This main fp-wrapper uses other fp-wrappers who link to those audio-libraries. Those fp-audio-wrappers have much more features than the c original audio-wrappers (dynamic loading, reference counters,...). Now the questions: 1) Is it possible to create a library from main fp-uos wrapper (including audio-libraries fp-wrappers, not the audio-libraries them-self) ? 2) If 1) = true, could you give me some advice how to do it ? 3) May that fp-uos library be accessible for other languages (C, java,...) ? 4) If 3) = true, what is the best way to create foreign-wrappers to that fp-uos-library (wrappers for C, java,...) ? Many thanks.

You might want to take a look here:
http://winff.org

Fred van Stappen
to Paul Breneman
You might want to take a look here: http://winff.org

Oops, Winff is fp... i did not know that.
So, no excuse, it is possible to do a universal fp library.

@ Leledumdo and Paul => many thanks.

PS : Because of fp, i need to study lot other languages now :-).

Fred

Fred van Stappen
to Fred van Stappen

Hello everybody.

Ok, i jump...

I decide to begin the conversion of a unit (wrapper to other libraries + lot of functions who link those libraries) into a universal fp library.

After Googling a while (and finding very poor doc, only few for Delphi, with always the hypra-simple same example...), i do not find how to do with classes...

Here a test (who gives me error)...
__________________________________________
library libtest;

uses
  Classes, ctypes, Math, SysUtils;
type
   TMyClass = class(TThread)
  public
  enabled1: boolean;
  int1, int2: shortint;
  function function1(): integer; cdecl;
  end;
function TMyClass.function1(): integer; cdecl;
begin
if enabled1 then
result := int1 + int2 else result := -1;
end;
exports
  TMyClass.function1();
end.
_______________________________________________________

Stop compil showing error at dot of function TMyClass.

=> libtest.pas(14,18) Fatal: Syntax error, ":" expected but "." found

PS : I promise, if i can do the conversion, to create a nice wiki, for dummies like me : "How to create a universal (complicated) library with fpc"...

Michael Van Canneyt
to Fred van Stappen
Fred van Stappen wrote
Hello everybody. Ok, i jump...

[snip]

Show quoted text 7 lines
Stop compil showing error at dot of function TMyClass. => libtest.pas(14,18) Fatal: Syntax error, ":" expected but "." found PS : I promise, if i can do the conversion, to create a nice wiki, for dummies like me : "How to create a universal (complicated) library with fpc"...

You cannot export classes from a library. Only regular functions and procedures.

Michael.

Fred van Stappen
to Michael Van Canneyt
Show quoted text 26 lines
Date: Sat, 1 Feb 2014 17:00:02 +0100 From: To: Subject: Re: [fpc-pascal] fp universal library ? On Sat, 1 Feb 2014, Fred van Stappen wrote: > Hello everybody. > > Ok, i jump... [snip] > > Stop compil showing error at dot of function TMyClass. > > => libtest.pas(14,18) Fatal: Syntax error, ":" expected but "." found > > PS : I promise, if i can do the conversion, to create a nice wiki, for dummies like me : "How to create a universal > (complicated) library with fpc"... You cannot export classes from a library. Only regular functions and procedures. Michael.

Aaaaarg, ok and many thanks to answer.

> Only regular functions and procedures.

Ok but those regular functions and procedures may use other custom classes ?

Many thanks.

Michael Van Canneyt
to Fred van Stappen
Fred van Stappen wrote 32 lines
> Date: Sat, 1 Feb 2014 17:00:02 +0100 > From: > To: > Subject: Re: [fpc-pascal] fp universal library ? > > > > On Sat, 1 Feb 2014, Fred van Stappen wrote: > > > Hello everybody. > > > > Ok, i jump... > > [snip] > > > > > Stop compil showing error at dot of function TMyClass. > > > > => libtest.pas(14,18) Fatal: Syntax error, ":" expected but "." found > > > > PS : I promise, if i can do the conversion, to create a nice wiki, for dummies like me : "How to create a universal > > (complicated) library with fpc"... > > You cannot export classes from a library. Only regular functions and procedures. > > Michael. Aaaaarg, ok and many thanks to answer. >> Only regular functions and procedures. Ok but those regular functions and procedures may use other custom classes ?

Not as arguments or result of the function.

How the function is implemented internally is another matter, but you cannot export classes.

You can export pointers, but you should make it so that the caller cannot cast them back to class instances. That may work for simple cases, but in it's generality it will not work.

If you want to make a generally usable library, restrict your exported interface to pointers and records.

Michael.

Fred van Stappen
to Michael Van Canneyt
Show quoted text 36 lines
> > On Sat, 1 Feb 2014, Fred van Stappen wrote: > > > > > Hello everybody. > > > > > > Ok, i jump... > > > > [snip] > > > > > > > > Stop compil showing error at dot of function TMyClass. > > > > > > => libtest.pas(14,18) Fatal: Syntax error, ":" expected but "." found > > > > > > PS : I promise, if i can do the conversion, to create a nice wiki, for dummies like me : "How to create a universal > > > (complicated) library with fpc"... > > > > You cannot export classes from a library. Only regular functions and procedures. > > > > Michael. > > Aaaaarg, ok and many thanks to answer. > > >> Only regular functions and procedures. > > Ok but those regular functions and procedures may use other custom classes ? Not as arguments or result of the function. How the function is implemented internally is another matter, but you cannot export classes. You can export pointers, but you should make it so that the caller cannot cast them back to class instances. That may work for simple cases, but in it's generality it will not work. If you want to make a generally usable library, restrict your exported interface to pointers and records. Michael.

Yep, thanks Michael.

Hum, may i export dynamic array ?

Fred van Stappen
to Sven Barth
Show quoted text 8 lines
> Yep, thanks Michael. > > Hum, may i export dynamic array ? No, you'll need to export these as (typed) pointers and a count. Regards, Sven

Re-Aaaaargh, ok, (and i understand now why the library-examples are so simple :-) ).

Many thanks for that brilliant explanations.

Ok, so i have to re-consider all the unit and forget the oop way and re-write more procedural (Yes/No ?).

hinst
to Fred van Stappen: Re-Aaaaargh, ok, (and i understand now why the library-examples are so simple :-) ). Many…

02.02.2014, 02:45, "Fred van Stappen" :

Show quoted text 14 lines
> > Yep, thanks Michael. > > > > Hum, may i export dynamic array ? > > No, you'll need to export these as (typed) pointers and a count. > > Regards, > Sven Re-Aaaaargh, ok, (and i understand now why the library-examples are so simple :-) ). Many thanks for that brilliant explanations. Ok, so i have to re-consider all the unit and forget the oop way and re-write more procedural (Yes/No ?).

I think it should be layered. I tried to visualize the idea; take a look plz http://s17.postimg.org/oc24gbc27/Untitled_Diagram.png One should not write all units in procedural style to make library accessible from other languages. A better approach is to create API layers. For example to make FPC library accessible from Java and C# consider creating the following layers: FPC Library core <-> FPC Library procedural layer
Procedural layer to Java OO
Procedural layer to C#
it should be like first API descends from OO level with FPC objects to procedural layer to make it accessible from java, then there should be java layer which "converts" it back from procedural flattened level to OO level with Java objects.

AFAIK some libraries are designed like this.
To further generalize the idea, consider this scheme: Language A OO <-> Language A proc. <-> dynamic lib <-> Language B proc. <-> Language B OO

So the point is: of course you should NOT rewrite ALL units. Create a procedural bridge instead and then bridges for other languages like I tried to explain Of course choosing the right approach for this task it is up to you because no one knows your library better than you

Fred van Stappen
to hinst
Show quoted text 37 lines
From: To: Date: Sun, 2 Feb 2014 15:31:00 +0400 Subject: Re: [fpc-pascal] fp universal library ? 02.02.2014, 02:45, "Fred van Stappen" : >> > Yep, thanks Michael. >> > >> > Hum, may i export dynamic array ? >> >> No, you'll need to export these as (typed) pointers and a count. >> >> Regards, >> Sven > > Re-Aaaaargh, ok, (and i understand now why the library-examples are so simple :-) ). > > Many thanks for that brilliant explanations. > > Ok, so i have to re-consider all the unit and forget the oop way and re-write more procedural (Yes/No ?). I think it should be layered. I tried to visualize the idea; take a look plz http://s17.postimg.org/oc24gbc27/Untitled_Diagram.png One should not write all units in procedural style to make library accessible from other languages. A better approach is to create API layers. For example to make FPC library accessible from Java and C# consider creating the following layers: FPC Library core <-> FPC Library procedural layer Procedural layer to Java OO Procedural layer to C# it should be like first API descends from OO level with FPC objects to procedural layer to make it accessible from java, then there should be java layer which "converts" it back from procedural flattened level to OO level with Java objects. AFAIK some libraries are designed like this. To further generalize the idea, consider this scheme: Language A OO <-> Language A proc. <-> dynamic lib <-> Language B proc. <-> Language B OO So the point is: of course you should NOT rewrite ALL units. Create a procedural bridge instead and then bridges for other languages like I tried to explain Of course choosing the right approach for this task it is up to you because no one knows your library better than you

Hello Hinstance and many thanks for advices.

What i will do is, like you said, not try to transform the actual working unit into a library but create a new file ( like the header file in c ) and in uses add the working unit. And that header file will be the "library" file with link to the working unit, with simple function-procedure...

I will give you news later.

Thanks

Fred van Stappen
to hinst: 02.02.2014, 02:45, "Fred van Stappen" : I think it should be layered. I tried to…

Hello everybody.

Here next episode of the conversion of a useful fp unit into a universal library...

The goal is to make a library from a unit used by programs. That unit has lot of complicated procedures-functions, inside some home-made classes, using many dynamic arrays who vary in length and data in real time. Also that procedures call other procedures from foreign dynamic loaded libraries and sent it back to other foreign libraries (after some modification by self-unit of course).

Lets call that unit 'myunit'.

Here first working steps: please advice if im on the wrong way... Many thanks.

1) Create a new file, name it mylib.pas and add this :

library mylib ;
use
myunit; /// the famous unit with all the procedures/functions, classes,...
begin
end.

(You have already done all the work !)

2) Add the functions-procedures you want from myunit in your library-code:

- Here example for general procedure, not inside a class:

library mylib ;
uses
myunit;
procedure mylibprocedure(); cdecl;
begin
  myunit.myprocedure(); /// a general procedure
end;
exports
mylibprocedure ;
begin
end.

- Here example for function inside a class of myunit:

library mylib ;
uses
myunit;
function mylibclassfunction() : integer; cdecl;
var
myclass : TMyUnitClass; /// class defined in myunit (if can be a variable outside the function)
begin
   result := -1 ;
   myclass := TMyUnitClass.Create;
   result := myclass.myunitclassfunction() ; // a function of myclass
end;
exports
mylibclassfunction ;
begin
end.

3) Add this compiler option : -fPIC (otherwise it does not compile on my 64 bit Linux)

4) Cross your fingers and compile it.

... And you know what : it compiles and it works !

I’m very happy with fpc, all is simple and accessible.

And, with the recent optimizations, fpc is formula 1 (f1pc)...

...............

Now the boring question :
Is it normal, even without debug-infos, with -Xs parameters, stripped,... that this library :

Library test ;
begin
end;

is 200k big ! ( mine, nude, only with "uses uos" is more than 1 mega ! ).

Many thanks for wonderful f1pc.

Fred

Christo
to Fred van Stappen: Hello everybody. Here next episode of the conversion of a useful fp unit into a universal…
Fred van Stappen wrote 25 lines
- Here example for function inside a class of myunit: library mylib ; uses myunit; function mylibclassfunction() : integer; cdecl; var myclass : TMyUnitClass; /// class defined in myunit (if can be a variable outside the function) begin result := -1 ; myclass := TMyUnitClass.Create; result := myclass.myunitclassfunction() ; // a function of myclass end; exports mylibclassfunction ; begin end.
Now what I would like in the compiler is a warning: potential memory
leak at myclass := TMyUnitClass.Create;

;)

Fred van Stappen
to Christo
Show quoted text 30 lines
- Here example for function inside a class of myunit: > > library mylib ; > > uses > myunit; > > function mylibclassfunction() : integer; cdecl; > var > myclass : TMyUnitClass; /// class defined in myunit (if can be a > variable outside the function) > > begin > result := -1 ; > myclass := TMyUnitClass.Create; > result := myclass.myunitclassfunction() ; // a function of > myclass > end; > > exports > mylibclassfunction ; > > begin > end. > Now what I would like in the compiler is a warning: potential memory leak at myclass := TMyUnitClass.Create; ;)

Yep, before to get that sympathetic message, i changed the code, now all the class.create are done inside the unit used by the library and i do not get the message...

Thanks.

Fred van Stappen
to Fred van Stappen
Now what I would like in the compiler is a warning: potential memory leak at myclass := TMyUnitClass.Create; ;)

Oops, prior message was cut...

Yep, before to get that sympathetic message, i changed the code, now all the class.create are done inside the unit used by the library and i will not get the message because i will not forget to free it before to close... ;-)

Thanks.

Fred van Stappen
to Fred van Stappen: Hello everybody. Here next episode of the conversion of a useful fp unit into a universal…

Hello everybody.

Here next episode of the conversion of a useful fp unit into a universal library...

After a hard battle, ... i win. But mainly because of the extremely high quality of fpc. The compiler gives me useful tips to realise that unique library. Unique because that dynamic loaded library load other libraries dynamically too.

Here some tips :

- If you use classes and threads in the unit you want to convert into library, it is a good idea to use dynamic arrays inside the unit. So the user dont have to create that classes in his program, only set length of array inside the unit (without to forget class.create, of course). That mainly for foreign language who will use your library (they could not create your fpc class but if all is done inside the library, no problem).

- If you use threads, do not forget to add, in linux , in uses section : cthreads.

- Warning : the exported name of function/proc are case sensible... Good to know before to loose (like me) lot of hair.

- The most strange (for me) is to create a "Pascal header". Usually, for library, i used h2pas, or c2pas, but here no ;-) . So no big problem to create the wrapper.

- Now i have to find : Pas2C, Pas2Java, Pas2Basic, Pas2Net,... (or some brave heart to help me to create wrappers for foreign language.)

Conclusion : fpc is FABULOUS.

Many thanks to all the creators and congrat for the high care you have done for Libraries compilation too.

PS : Im very, very happy, till now, all my wishes become truth with fpc.

PS : I have tested the lib and it works ( dynamic load other lib too ). I can play songs with effects perfectly. Now i have to find a way to export-import the data-buffer (dynamic array of float) . But that is for the "custom user DSP" feature, all the bild-in DSP provided by uos-unit are working perfectly.

Fred.

Fred van Stappen
to Fred van Stappen: Oops, prior message was cut... Yep, before to get that sympathetic message, i changed the…

Hello.

Here next episode of the conversion of a useful unit into a universal library. In a recent topic i was taking about the total victory of the conversion in Linux OS. Now im fighting to do it in Windows.
I have Windows 7-64 bit.
If compiling the library with fpc-64bit, all is working perfectly. A 64bit-program can access all the functions of the library. But, compiling the library with fpc-32bit, if a 32bit-program try to access the 32bit-library, i get that error message :

C:\Users\moi>gdb c:\uoslibwin\src\uoslibtest.exe
(gdb) run
Starting program: c:\uoslibwin\src\uoslibtest.exe
[New Thread 3060.0x2b0]
Program received signal SIGSEGV, Segmentation fault. 0x10002c40 in uos_AddDSPVolumeIn () from c:\uoslibwin\src\uos.dll (gdb)

And here with extended gdb
Program received signal SIGSEGV, Segmentation fault. 0x10002cf0 in SYSTEM_$$_CPUINCLOCKED$LONGINT () from c:\uoslibwin\src\uos.dll (gdb)

I have changed all cdecl into stdcall but without luck...

Does the fpc-32 bit libraries work only on a Windows-32bit system (or did i do something wrong ?) Will it be the same for Linux-32bit (inside a multi-arch 64bit system) ?

Many thanks.

Fred.

Sven Barth
to Fred van Stappen
Fred van Stappen wrote
I have changed all cdecl into stdcall but without luck...

Did you change the calling convention for both the import and the export code? (just a sidenote: on Linux you should use cdecl no matter what if you want your library to be used by other languages and preferably stdcall on Windows (makes a difference only on i386 as for ARM and x86_64 (and other CPUs) stdcall maps to cdecl))

Does the fpc-32 bit libraries work only on a Windows-32bit system (or did i do something wrong ?) Will it be the same for Linux-32bit (inside a multi-arch 64bit system) ?

Without some code it's hard to tell what the problem might be. Normally it should work, so likely there's a problem in your code that only manifests on Win32 or there is (less likely) a bug in the compiler/RTL. So if you could minimize your code as much as possible and test then, this would be favorable.

Regards,
Sven

Fred van Stappen
to Sven Barth
I have changed all cdecl into stdcall

but without luck...

Did you change the calling convention for both the import and the

export

code? (just a sidenote: on Linux you should use cdecl no

matter what ifnt >your library to be used by other languages and preferably stdcall on

Windows (makes a difference only on i386

as for ARM and x86_64 (and

other CPUs) stdcall maps to cdecl))
Does the fpc-32 bit libraries work only on a

Windows-32bit system

(or did i do something wrong ?) Will it be the same for Linux-32bit (inside a multi-arch 64bit system) ?
Without some code it's hard to tell what the problem might be.

Normally it

should work, so likely there's a problem in your code

that only manifests on >Win32 or there is (less likely) a bug in the compiler/RTL. So if you could >minimize your code as much as possible and test then, this would be >favorable.

Many thanks Sven.

I have changed stdcall cdecl in both import-export, with no luck. I will do a "Hello World" library to see if problem is still there (because the code of uos is big.).

See you later with the result.

Fred

Fred van Stappen
to Sven Barth: Did you change the calling convention for both the import and the export code? (just a…

Hello.

Here next adventure of uos library...

I have good news for fpc. ;-)
I have try with a "hello world" 32bit library in Windows 7 64bit. It works, a 32bit program can access a 32bit fpc library.

But i have bad news for me. :-(

I have try with uoslib, and try, and try, changing everything, but still same error message: Program received signal SIGSEGV, Segmentation fault. 0x10002cf0 in SYSTEM_$$_CPUINCLOCKED$LONGINT () from c:\uoslibwin\src\uos.dll

I do not see the solution.

If a brave heart could try it, he will be my hero. ;-)

This is very easy.
All is included, you dont have to install anything...

First download the source here :

Unzip it and in /uoslibtest/src :

1) Compile uoslib.pas (or uoslib.lpi) => it will create uos.dll in /src.
2) Compile and run libconsoleplay.pas (or libconsoleplay.lpi) => it will test the library.

For me, it works if i compile both library and example with fpc 64 bit. But it crash if i compile both library and example with fpc 32 bit.

In /src there is also unitconsoleplay.pas (and unitconsoleplay.lpi). This program uses directly uos-unit, not via uoslib library. And, this one on Windows 7 64bit, works compiled with fpc 32bit...

Many thanks.
Fred.

Sandro Cumerlato
to Fred van Stappen

Hello Fred,
change these two lines:

uos.pas line 1086:
    RTLeventSetEvent(evPause);
uoslib.pas line 41:
function uos_loadlib(PortAudioFileName: string; SndFileFileName:
string; Mpg123FileName: string; SoundTouchFileName: string) : integer;
cdecl;

Sandro

Fred van Stappen wrote 48 lines
Hello. Here next adventure of uos library... I have good news for fpc. ;-) I have try with a "hello world" 32bit library in Windows 7 64bit. It works, a 32bit program can access a 32bit fpc library. But i have bad news for me. :-( I have try with uoslib, and try, and try, changing everything, but still same error message: Program received signal SIGSEGV, Segmentation fault. 0x10002cf0 in SYSTEM_$$_CPUINCLOCKED$LONGINT () from c:\uoslibwin\src\uos.dll I do not see the solution. If a brave heart could try it, he will be my hero. ;-) This is very easy. All is included, you dont have to install anything... First download the source here : >> https://sites.google.com/site/fiensprototyping/uoslibtest.tar.gz Unzip it and in /uoslibtest/src : 1) Compile uoslib.pas (or uoslib.lpi) => it will create uos.dll in /src. 2) Compile and run libconsoleplay.pas (or libconsoleplay.lpi) => it will test the library. For me, it works if i compile both library and example with fpc 64 bit. But it crash if i compile both library and example with fpc 32 bit. In /src there is also unitconsoleplay.pas (and unitconsoleplay.lpi). This program uses directly uos-unit, not via uoslib library. And, this one on Windows 7 64bit, works compiled with fpc 32bit... Many thanks. Fred. _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Tomas Hajny
to Fred van Stappen: Hello. Here next adventure of uos library... I have good news for fpc. ;-) I have try…

On Tue, February 11, 2014 16:52, Fred van Stappen wrote: .
.

Show quoted text 7 lines
First download the source here : >> https://sites.google.com/site/fiensprototyping/uoslibtest.tar.gz Unzip it and in /uoslibtest/src : 1) Compile uoslib.pas (or uoslib.lpi) => it will create uos.dll in /src.

.
.

It might be better to mention the necessary compiler options (-Mobjfpc -Sh) or even better include them directly in the respective sources.

In addition, compiling "uoslib.pas" results in "uoslib.dll", whereas you try to load uos.dll from libconsoleplay.pas.

GDB gives the following backtrace:

0x10002950 in SYSTEM_CPUINCLOCKED$LONGINT () from D:\TEMP\T\src\uoslib.dll (gdb) bt
#0 0x10002950 in SYSTEM_CPUINCLOCKED$LONGINT () from D:\TEMP\T\src\uoslib.dll
#1 0x10005195 in fpc_ansistr_incr_ref () from D:\TEMP\T\src\uoslib.dll #2 0x10001577 in UOS_LOADLIB (
PORTAUDIOFILENAME=0x10001560
'U'#137'ĺ'#131'ě8'#137'Eü'#137'Uř'#137'Mô'#139'Eüčů;', SNDFILEFILENAME=0x10000000 'MZ'#144, MPG123FILENAME=0x10000000 'MZ'#144, SOUNDTOUCHFILENAME=0x90ae8
'D:\TEMP\T\src\lib\Windows\32bit\LibPortaudio-32.dll') at uoslib.pas:43
#3 0x0040d6b1 in UOS_LOADLIBS (UOSLIBFILENAME=0x68028 'D:\TEMP\T\src\uoslib.dll',
PORTAUDIOFILENAME=0x90ae8
'D:\TEMP\T\src\lib\Windows\32bit\LibPortaudio-32.dll', SNDFILEFILENAME=0x90b28
'D:\TEMP\T\src\lib\Windows\32bit\LibSndFile-32.dll', MPG123FILENAME=0x0, SOUNDTOUCHFILENAME=0x0) at uoslib_h.pas:347 #4 0x00401670 in CONSOLEPLAY (this=0x98ab8) at libconsoleplay.pas:79 #5 0x00401864 in DORUN (this=0x98ab8) at libconsoleplay.pas:102 #6 0x004211f4 in CUSTAPP_TCUSTOMAPPLICATION_$__RUN () #7 0x00401a2f in main () at libconsoleplay.pas:127

It turns out that you missed to specify a matching calling convention for uos_loadlib (you specified "cdecl" in uoslib_h, but not in uoslib). It seems to work correctly after adding it at line 41 of uoslib.pas.

Tomas

Fred van Stappen
to Tomas Hajny
Show quoted text 5 lines
It might be better to mention the necessary compiler options (-Mobjfpc -Sh) or even better include them directly in the respective sources. In addition, compiling "uoslib.pas" results in "uoslib.dll", whereas you try to load uos.dll from libconsoleplay.pas.

Yep, sorry. But if you compile it from uoslib.lpi, it change uoslib.dll into uos.dll. Also, compiling from uoslib.lpi include extrafpc.cfg, with required compiler options.

It turns out that you missed to specify a matching calling convention for uos_loadlib (you specified "cdecl" in uoslib_h, but not in uoslib). It seems to work correctly after adding it at line 41 of uoslib.pas.

Houraaa, magnifique, marvellous, you find it.
Gigas of thanks, Tomas, you are my Hero.

Of course you get a big credit in the uoslib contributors.

Yep, it will be a good night for me...

Many, many thanks.

Fred.

Tomas Hajny
to Fred van Stappen
Fred van Stappen wrote 11 lines
> It might be better to mention the necessary compiler options (-Mobjfpc > -Sh) or even better include them directly in the respective sources. > > In addition, compiling "uoslib.pas" results in "uoslib.dll", whereas you > try to load uos.dll from libconsoleplay.pas. Yep, sorry. But if you compile it from uoslib.lpi, it change uoslib.dll into uos.dll. Also, compiling from uoslib.lpi include extrafpc.cfg, with required compiler options.

I don't use Lazarus, i.e. .lpi files are of no use for me. The option -fPIC isn't necessary for the Win32 target, i.e. I didn't miss that one (but I was aware of it - at least it was well visible unlike the others which I had to find by trial and error).

Show quoted text 9 lines
> It turns out that you missed to specify a matching calling convention > for > uos_loadlib (you specified "cdecl" in uoslib_h, but not in uoslib). It > seems to work correctly after adding it at line 41 of uoslib.pas. Houraaa, magnifique, marvellous, you find it. Gigas of thanks, Tomas, you are my Hero. Of course you get a big credit in the uoslib contributors.

You're welcome, it wasn't that difficult after all. :-)

Tomas

Fred van Stappen
to Tomas Hajny
I don't use Lazarus, i.e. .lpi files are of no use for me. The option -fPIC isn't necessary for the Win32 target, i.e. I didn't miss that one (but I was aware of it - at least it was well visible unlike the others which I had to find by trial and error).

Ok and thanks to note it. Hum, i have adapted all the uos-unit-examples for uoslib.

The good news :

All pure fpc programs and graphical using fpGUI are working perfectly. The programs dealing with uoslib can access uoslib procedures and result of functions. Perfect, perfect, perfect...
PS : I do not try yet to access the uoslib from foreign language (C, Cnet, Java,...). PS2 : Little bemol, (but i think i ask to much for the library here), the library cannot synchronize procedure of object from the program.

The bad news :

All programs using LCL (Lazarus widgetset) crash after thread.terminate inside the library... I dont know why, it is the same code and the same library. Maybe i have to do something but i dont know what. Using directly the uos unit, without using the library, is ok for LCL.

>> It turns out that you missed to specify a matching calling convention >> for >> uos_loadlib (you specified "cdecl" in uoslib_h, but not in uoslib). It >> seems to work correctly after adding it at line 41 of uoslib.pas.

Aaarg, it was at the first procedure, i read and re-read the code thousand times and dont see it... Many thanks to have better eyes than mine... ;-)

You're welcome, it wasn't that difficult after all. :-)

Maybe for you, but for me, i became crazy...

Re-thanks.

Fred

Fred van Stappen
to Fred van Stappen
Show quoted text 6 lines
The bad news : All programs using LCL (Lazarus widgetset) crash after thread.terminate >inside the library... I dont know why, it is the same code and the same library. Maybe i have to do something but i dont know what. Using directly the uos unit, without using the library, is ok for LCL.

Ye, today good news for LCL.
I find the guilty. It is => cmem !
I used cmem in all LCL example and fp libraries do not like cmem...

PS: I will do a other topic to note it...

Conclusion : everything is working perfectly.

Thank you fpc...

Fred

Fred van Stappen
to Fred van Stappen

Hello everybody.

I am extremely happy to announce the birth of the universal uos library version 1.0.

uos (United Open-libraries of Sound) unifies the best open-source audio libraries.

With uos you can:

. Listen to mp3, ogg, wav, flac,... audio files.
. With 16, 32 or float 32 bit resolution.
. Record all types of input into file.
. Add DSP effects and filters, however many you want and record it. . Listen to multiple inputs and outputs.

uos uses the SoundTouch, PortAudio, SndFile and Mpg123 audio libraries.

You may download the source here :

Here compiled examples :

PS : Till now, there is only a Pascal header but, because uoslib is universal, other headers for foreign languages (C, CNet, Java,...) are super-welcome.

Fred.

Michael Schnell
to Fred van Stappen
Fred van Stappen wrote 6 lines
I am extremely happy to announce the birth of the universal uos library version 1.0. uos (United Open-libraries of Sound) unifies the best open-source audio libraries.

GREAT !!!!

Any documentation to make this usable ?

-Michael

Fred van Stappen
to Michael Schnell
Show quoted text 5 lines
GREAT !!!! Any documentation to make this usable ? -Michael

All the examples have lot of explanations. ;-)

There is also a wiki for uos : >> http://wiki.lazarus.freepascal.org/uos

The only things to change for uoslib are:

In uses section, add uoslib_h in place of uos.

And to load libraries :
For uos library :
uos_LoadLibs(uoslibFilename, PortAudioFileName, SndFileFileName, Mpg123FileName, SoundTouchFileName);

in place of (for uos unit) :
uos_LoadLib(PortAudioFileName, SndFileFileName, Mpg123FileName, SoundTouchFileName);

Thanks.

Fred.

PS : I will do a wiki for uoslib too.

Michael Schnell
to Fred van Stappen
Fred van Stappen wrote
There is also a wiki for uos : >> http://wiki.lazarus.freepascal.org/uos

Looks nice.

I wonder if uos would allow for this use of DSP-Effects:

- read a wav file and output it to a new wav file ("playing" it is not necessary/sensible here)
- on the fly "insert" a DSP effect (i.e. run the samples through an effect processor)
- the parameter(s) of the effect should be changed on the fly (with each sample)

- in this case the DSP effect should be a low pass filter
- the edge-frequency of the filter should be modified under control of the user program.

-Michael

Fred van Stappen
to Michael Schnell: Looks nice. I wonder if uos would allow for this use of DSP-Effects: - read a wav file…
> I wonder if uos would allow for this use of DSP-Effects: >- read a wav file and output it to a new wav file ("playing" it is

not necessary/sensible here)

>on the fly "insert" a DSP effect (i.e. run the samples through an

effect processor)

> the parameter(s) of the effect should be changed on the fly (with

each sample)

> in this case the DSP effect should be a low pass filter > the edge-frequency of the filter should be modified under control

of the user program.

Hum, it seems to me that all that can already be done by uos. For uoslib, the difficult thing is to find a "universal" way to parse parameters for custom dsp. It is absolutely not impossible but i want to find a simple "look" for custom dsp.

But for filters or bild-in DSP, it works (have you try FilterPlayer, SimplePlayer and SimpleRecorder examples ?)

Thanks.

Fred.