Yep, yep, yep, i get it...
I will (try) to explain the thing...
The error comes mainly because i was focused on SoundTouchDLL.h. (Thanks to
Ludo).
That wrapper is for windows only.
Before to call a DSP-buffer-procedure, you must do :
FHandle := soundtouch_createInstance();
But the result of n
On 17 Jan 2014, at 21:14, Fred van Stappen wrote:
> >Ha, then you use/compiled a different version. Since a `extern "C"` preserves
> > the symbol name (that is the trick I use to link in a lot of external C++
> > code:
> >just put extern "C" in front of the symbol). or it could be that I am
> >
> That routine is defined in SoundTouchDLL.cpp which is the windows dll
> wrapper. Do you have the linux equivalent?
Oops, im full of doubt now...
Do you think the SoundTouchDLL.h wrapper is for Windows only ( and, yes, the
old wrapper uses stdcall (who is windows only)).
And for linux how does
>Ha, then you use/compiled a different version. Since a `extern "C"` preserves
> the symbol name (that is the trick I use to link in a lot of external C++
> code:
>just put extern "C" in front of the symbol). or it could be that I am
>completely
>missing something here. [for example: is the symbo
On 17 Jan 2014, at 20:40, Fred van Stappen wrote:
>
> Yep, there is a brand new wrapper from trunk :
Ha, then you use/compiled a different version. Since a `extern "C"` preserves
the symbol name (that is the trick I use to link in a lot of external C++ code:
just put extern "C" in front of th
> Yep, there is a brand new wrapper from trunk :
Of course, all the tests i have done are with that new wrapper...
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/m
> Note one detail: it is declared there as __stdcall, not as __cdecl, so
> perhaps this has something to do with it?
>
> @Fred: Also note that the type HANDLE is defined there as a pointer, so [as a
> sanity test of sorts] sizeof(Handle {in pascal}) should be equal to
> sizeof(HANDLE /*in C/C+
> That routine is defined in SoundTouchDLL.cpp which is the windows dll
> wrapper. Do you have the linux equivalent?
>
> Ludo
PS : For new new arriving : SoundTouchDLL.cpp is part of SoundTouch, a audio
processing library :
>> http://www.surina.net/soundtouch/download.html
@ Ludo :
In /sourc
On 17 Jan 2014, at 17:25, Ludo Brands wrote:
> On 01/17/2014 05:09 PM, Fred van Stappen wrote:
>>
>>> I don't know if the Handle type in the header is defined by the C++
>> compiler
>>> or by the package itself. Consult their respective documentation for more
>>> info.
>>
>> Here declaration of
On 01/17/2014 05:09 PM, Fred van Stappen wrote:
>
>> I don't know if the Handle type in the header is defined by the C++
> compiler
>> or by the package itself. Consult their respective documentation for more
>> info.
>
> Here declaration of create instance :
>
> // Create a new instance of Soun
> I don't know if the Handle type in the header is defined by the C++ compiler
> or by the package itself. Consult their respective documentation for more
> info.
Here declaration of create instance :
// Create a new instance of SoundTouch processor.
SOUNDTOUCHDLL_API HANDLE __cdecl soundtouch_c
> Writeln(sizeof(THandle)); // for console apps
FHandle := soundtouch_createInstance();
writeln(FHandle);
Writeln(sizeof(FHandle));
Gives that result :
10321232
4
> I don't know if the Handle type in the header is defined by the
> C++ compiler or by the package itself.
> Consult their respect
In our previous episode, Fred van Stappen said:
> > Handle is not defined on Linux. Many libraries emulate some handle type, but
> > it depends on the vendor if they make handle 32-bit or 64-bit.
> >
> > Make sure that sizeof(HANDLE) in C++ matches sizeof(THandle) in FPC. Adjust
> > the type you
> What is the value of the handle that was returned?
>
> Ludo
Re-hello Ludo.
That code :
if ST_Load('/home/fred/dynlib_vs_windows/libSoundTouch.so') then
writeln('libSoundTouch.so loaded');
if FHandle <> NilHandle then soundtouch_clear(FHandle);
FHandle := soundtouch_createInstance();
> On 01/17/2014 03:55 PM, Fred van Stappen wrote:
> >
> >> > I run nm and find the name of the procedures ( PS : without
> > nm-Ewald's tip, you must be a high soothsayer to find it)
> >> > For example, a C called procedure : soundtouch_getVersionString()
> > becomes : _ZN10soundtouch10SoundTouch
On 01/17/2014 03:55 PM, Fred van Stappen wrote:
>
>> > I run nm and find the name of the procedures ( PS : without
> nm-Ewald's tip, you must be a high soothsayer to find it)
>> > For example, a C called procedure : soundtouch_getVersionString()
> becomes : _ZN10soundtouch10SoundTouch16getVersionS
> Subject: Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
>
> In our previous episode, Fred van Stappen said:
> > I have only a problem with one procedure:
> >
> > This c procedure is declared as this :
> > SOUNDTOUCHDLL_API void __cdecl
In our previous episode, Fred van Stappen said:
> I have only a problem with one procedure:
>
> This c procedure is declared as this :
> SOUNDTOUCHDLL_API void __cdecl soundtouch_setSampleRate(HANDLE h, unsigned
> int srate);
>
> And i translate it like that :
>
> soundtouch_setSampleRate : pro
> I only have problem with :
> _ZN10soundtouch10SoundTouch16getVersionStringEv()...
Ooops, have to read :
I only have problem with :
Pointer(soundtouch_setSampleRate):= GetProcAddress(LibHandle,
Pchar('_ZN10soundtouch10SoundTouch13setSampleRateEj'));
> > I run nm and find the name of the procedures ( PS : without nm-Ewald's tip,
> > you must be a high soothsayer to find it)
> > For example, a C called procedure : soundtouch_getVersionString() becomes :
> > _ZN10soundtouch10SoundTouch16getVersionStringEv() !!!
> >
>
> The _ZN10soundtouch10S
On 01/17/2014 03:16 PM, Fred van Stappen wrote:
>
> I run nm and find the name of the procedures ( PS : without nm-Ewald's tip,
> you must be a high soothsayer to find it)
> For example, a C called procedure : soundtouch_getVersionString() becomes :
> _ZN10soundtouch10SoundTouch16getVersionStri
Hello.
Thanks to Mister Hinst, i was able to load and run, in Windows, with
dynlib.pas, SoundTouch.dll. Perfect and re-thanks.
Now, i begin a other hard battle : load and run in Linux, libSoundTouch.so.
With the extremely helpful message of Mister Ewald :> Try to find the names of
the symbols
@
Hinst, Michael, Tomas, Mark, Lukasz, Ewald, Marco, Sven and Waldo :
MANY, MANY THANKS.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pasca
> I identified the problem
Mr Hint : you are magic...
I cannot find words...
1.000 gigas of thanks ( even more...).
Of course you get a big credit in uos project.
Fred
___
fpc-pascal maillist - f
On Tue, 14 Jan 2014, Sven Barth wrote:
Am 14.01.2014 09:24 schrieb "Sven Barth" :
> Maybe an overload could be added to load functions by ordinal on Windows and
which simply returns Nil on other platforms.
I've now added an overload which is implemented for the Windows systems and
returns
Am 14.01.2014 09:24 schrieb "Sven Barth" :
> Maybe an overload could be added to load functions by ordinal on Windows
and which simply returns Nil on other platforms.
I've now added an overload which is implemented for the Windows systems and
returns Nil on other targets.
For Delphi compatibility
Am 14.01.2014 13:21 schrieb "Fred van Stappen" :
>
> >Now, for the windows version, I don't know what underlying mechanism
> >dynlibs uses under windows, so I'm afraid I can't really comment on that
>platform, except that you could try a similar approach as on linux (use
symbol
> >names instead of
Am 14.01.2014 14:02 schrieb "Tomas Hajny" :
>
> On Tue, January 14, 2014 09:24, Sven Barth wrote:
> > Am 14.01.2014 00:12 schrieb "Ewald" :
> >> On 13 Jan 2014, at 23:06, Fred van Stappen wrote:
> >>
> >>> The SoundTouch.dll uses index to call the procedures.
> .
> .
> > No, ordinals are not supp
On Tue, January 14, 2014 09:24, Sven Barth wrote:
> Am 14.01.2014 00:12 schrieb "Ewald" :
>> On 13 Jan 2014, at 23:06, Fred van Stappen wrote:
>>
>>> The SoundTouch.dll uses index to call the procedures.
.
.
> No, ordinals are not supported on non-Windows (or more precisely non-PE)
> systems.
Th
I identified the problem
Take a look at the function declaration plz:
Function GetProcAddress(Lib : TlibHandle; const ProcName : AnsiString) :
Pointer; // from dynlibs
It internally uses this function:
Function GetProcedureAddress(Lib : TLibHandle; const ProcName : AnsiString) :
Pointer;
> fred, can you please adjust your quoting to use the standard '>' for previous
> responses and then add your response below? you do add your response below
> but
> the quote is the exact of the previous and it is very hard to read only your
> responses when the previous is not prefixed by '>'.
>Now, for the windows version, I don't know what underlying mechanism
>dynlibs uses under windows, so I'm afraid I can't really comment on that
>>platform, except that you could try a similar approach as on linux (use symbol
>names instead of indices). OTOH it could (?) be that the the compiler in
Am 14.01.2014 12:04 schrieb "Marco van de Voort" :
>
> In our previous episode, Sven Barth said:
> >
> > Maybe an overload could be added to load functions by ordinal on Windows
> > and which simply returns Nil on other platforms.
>
> I thought the index feature originated in win3.x and was mostly
In our previous episode, Sven Barth said:
>
> Maybe an overload could be added to load functions by ordinal on Windows
> and which simply returns Nil on other platforms.
I thought the index feature originated in win3.x and was mostly considered
deprecated by MS?
__
Am 14.01.2014 00:12 schrieb "Ewald" :
>
>
> On 13 Jan 2014, at 23:06, Fred van Stappen wrote:
>
>> The SoundTouch.dll uses index to call the procedures.
>>
>> Like that :
>> [Ordinal/Name Pointer]
>> [ 0] soundtouch_clear
>> [ 1] soundtouch_createInstance
>> [ 2] soundtouch_destr
fred, can you please adjust your quoting to use the standard '>' for previous
responses and then add your response below? you do add your response below but
the quote is the exact of the previous and it is very hard to read only your
responses when the previous is not prefixed by '>'... thanks
On 13 Jan 2014, at 23:06, Fred van Stappen wrote:
> The SoundTouch.dll uses index to call the procedures.
>
> Like that :
> [Ordinal/Name Pointer]
> [ 0] soundtouch_clear
> [ 1] soundtouch_createInstance
> [ 2] soundtouch_destroyInstance
>
That explains why it works in win
From: ew...@yellowcouch.org
Date: Mon, 13 Jan 2014 21:25:27 +0100
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
On 13 Jan 2014, at 17:33, Fred van Stappen wrote:Hello and many thanks to help.
Here demo to show the problem (i
On 13 Jan 2014, at 17:33, Fred van Stappen wrote:
> Hello and many thanks to help.
>
> Here demo to show the problem (i hope).
>
> >> https://sites.google.com/site/fiensprototyping/dynlib_vs_windows.zip
in the dynlibs version, why do you use `PChar(1)` or `PChar(2)` [or ]
instead of the
From: fi...@hotmail.com
To: fpc-pascal@lists.freepascal.org
Date: Mon, 13 Jan 2014 17:33:47 +0100
Subject: Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
Hello and many thanks to help.
Here demo to show the problem (i hope).
>> https://sites.google.co
Hello and many thanks to help.
Here demo to show the problem (i hope).
>> https://sites.google.com/site/fiensprototyping/dynlib_vs_windows.zip
There is a program : test.pas
It uses a external library soundtouch_2.dll.
There are 2 wrappers :
soundtouch_windows.pas (who uses windows unit) and
so
On 13/01/14 13:36, Fred van Stappen wrote:
[...]
> Hello Lucaz
>
> /// why not just :
>>
>> @soundtouch_createInstance := DynLibs.GetProcedureAddress(LibHandle,
>> PAnsiChar('soundtouch_createInstance'));
>>
>
> Get that error :
>
>>> libSoundTouch.pas(56,5) Error: Can't assign values to an ad
> To: fpc-pascal@lists.freepascal.org
> From: el.es...@gmail.com
> Date: Mon, 13 Jan 2014 12:52:51 +
> Subject: Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
>
> Hi,
>
> 'scue me if I did not catch something, but
>
> On 13/
> To: fpc-pascal@lists.freepascal.org
> From: el.es...@gmail.com
> Date: Mon, 13 Jan 2014 12:52:51 +
> Subject: Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
>
> Hi,
>
> 'scue me if I did not catch something, but
>
> On 13/
On Mon, 13 Jan 2014, Fred van Stappen wrote:
>
> On Mon, 13 Jan 2014, Fred van Stappen wrote:
>
>
> > > > begin
> > > > LibHandle:=DynLibs.LoadLibrary(libfilename);
> > > > if LibHandle <> DynLibs.NilHandle then
> > > >
> > > > Pointer(soundtouch_createInstance):=
> > > > Dyn
Hi,
'scue me if I did not catch something, but
On 13/01/14 12:13, Fred van Stappen wrote:
[...]
>> > procedure InitLib(LibFile : PAnsiChar);
>> > begin
>> > LibHandle:=DynLibs.LoadLibrary(libfilename);
>> > if LibHandle <> DynLibs.NilHandle then
>> >
>> > Pointer(soundtouch_createInsta
On Mon, 13 Jan 2014, Fred van Stappen wrote:
On Mon, 13 Jan 2014, Fred van Stappen wrote:
> > > begin
> > > LibHandle:=DynLibs.LoadLibrary(libfilename);
> > > if LibHandle <> DynLibs.NilHandle then
> > >
> > > Pointer(soundtouch_createInstance) :=
DynLibs.GetProcedureAddre
On Mon, 13 Jan 2014, Fred van Stappen wrote:
> > > begin
> > > LibHandle:=DynLibs.LoadLibrary(libfilename);
> > > if LibHandle <> DynLibs.NilHandle then
> > >
> > > Pointer(soundtouch_createInstance):=
> > > DynLibs.GetProcedureAddress(LibHandle,
> > > PAnsiChar('soundtouch_c
On Mon, 13 Jan 2014, Fred van Stappen wrote:
> > begin
> > LibHandle:=DynLibs.LoadLibrary(libfilename);
> > if LibHandle <> DynLibs.NilHandle then
> >
> > Pointer(soundtouch_createInstance) :=
DynLibs.GetProcedureAddress(LibHandle, PAnsiChar('soundtouch_createInstance
'));
>
On Mon, 13 Jan 2014, Fred van Stappen wrote:
> Date: Mon, 13 Jan 2014 12:32:53 +0100
> From: mich...@freepascal.org
> To: fpc-pascal@lists.freepascal.org
> Subject: Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
>
>
>
> On Mon, 13 Jan 2014
On Mon, 13 Jan 2014, Fred van Stappen wrote:
Date: Mon, 13 Jan 2014 12:32:53 +0100
From: mich...@freepascal.org
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
On Mon, 13 Jan 2014, Fred van Stappen wrote:
>
> &g
Date: Mon, 13 Jan 2014 12:32:53 +0100
From: mich...@freepascal.org
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
On Mon, 13 Jan 2014, Fred van Stappen wrote:
>
> >>> Here part of NOT working
Tomas Hajny wrote:
On Mon, January 13, 2014 11:47, Fred van Stappen wrote:
Hello.
I have a external dll. In Windows i can access perfectly the procedures
with
GetProcAddress() if i use Windows unit.
If i use DynLibs unit, prog crash when i try to load the procedure.
I prefer to use DynLibs uni
> Date: Mon, 13 Jan 2014 12:07:54 +0100
> From: xhaj...@hajny.biz
> To: fpc-pascal@lists.freepascal.org
> Subject: Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
>
> On Mon, January 13, 2014 11:47, Fred van Stappen wrote:
> > Hello.
> >
> &g
On Mon, 13 Jan 2014, Fred van Stappen wrote:
>>> Here part of NOT working code (if i call soundtouch_createInstance, it
crash)
...
uses
dynlibs ;
...
var
soundtouch_createInstance : function() : THandle; stdcall;
...
procedure InitLib(LibFile : PAnsiChar);
begin
LibHandle:=DynLibs.Load
> Date: Mon, 13 Jan 2014 11:58:21 +0100
> From: mich...@freepascal.org
> To: fpc-pascal@lists.freepascal.org
> Subject: Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
>
>
>
> On Mon, 13 Jan 2014, Fred van Stappen wrote:
>
> > Hello.
&
On Mon, January 13, 2014 11:47, Fred van Stappen wrote:
> Hello.
>
> I have a external dll. In Windows i can access perfectly the procedures
> with
> GetProcAddress() if i use Windows unit.
>
> If i use DynLibs unit, prog crash when i try to load the procedure.
> I prefer to use DynLibs unit becaus
On Mon, 13 Jan 2014, Fred van Stappen wrote:
Hello.
I have a external dll. In Windows i can access perfectly the procedures with
GetProcAddress() if i use Windows unit.
If i use DynLibs unit, prog crash when i try to load the procedure.
I prefer to use DynLibs unit because i want to use the
Hello.
I have a external dll. In Windows i can access perfectly the procedures with
GetProcAddress() if i use Windows unit.
If i use DynLibs unit, prog crash when i try to load the procedure.
I prefer to use DynLibs unit because i want to use the dll for Linux too (of
course with library.so).
I
59 matches
Mail list logo
