▲

[fredvs]

Hi DanaPaul.

OK, it compile, i dont have error message anymore, the program works (i must deep try it) but when i close the app, first i do a bass_free and i get a error message "Handle is invalid" then, after (application.terminate) it crash.

I have try to use your unloadbassdll function, but the same occurs.

I m shure you get the answer.

Bye the way, bravo, great work, it functionates, and now i will test all the functions. (Have you try it with MixK that use the original bass.pas, i dont have find any problems, but i trust you, bass.pas with only comp variable could generate error, but it never occurs with me at the moment... ?)

NB It was not so easy to transform it for bass2.pas to use for bass2.dll (for multiple sound cards), but ok, i have done it and it seems to work too (without application.terminate of course)...

[DanaPaul]

when i close the app, first i do a bass_free and i get a error message "Handle is invalid" then, after (application.terminate) it crash.

I have try to use your unloadbassdll function, but the same occurs.

You don't need to call BASS_Free nor UnloadBassDll.  This has already been taken care of in the Bass_18.pas header file.

Neither of these functions are necessary, nor advised in any "Application.OnTerminate" event nor "Finalization" unit section.

One of the problems with static library linking is that the order of libraries loaded during exe launch depends on the order of unit placement in your application.  You have little control over whether BassWMA.dll is loaded before Bass.dll or visa versa.

The same holds true for the order in which Finalization sections in your units are called.  You have little control whether the Finalization section in Bass_18.pas is called before (or after) BassWMA.pas.

An effective solution is to dynamically load libraries and manually code library loading in objects.  Example...

Form.OnShow
  BassDllLoad
  BASS_Init
  BassWMADllLoad
  end

Form.Destroy
  UnloadBassWMADll
  BASS_Free
  UnloadBassDll
  end

I have posted a BassWMA.pas header file that dynamically loads BassWMA.dll just as Bass_18.pas loads Bass.dll.

While at the site, please download a fresh copy of Bass_18.pas.  It already has your DWORD Cardinal type assignment restored and a couple other minor improvements.

[fredvs]

Hi Dana,

It seems to work well but i have problem with bass2.dll (the second card).
When i load :

BASS2_ChannelSetPosition ;
 
I get a BASS2_ERROR_POSITION : raise EBass2Exception.Create(sSeekPositionIllegal);

I dont undrstand why ?

[DanaPaul]

It has been my experience that Bass.dll will return this error when trying to seek past the end of a file.  You could ignore this error message by trapping the Exception, or test for seek near end of file before calling the function.

[fredvs]

Thanks, but why now, i never get error, do you add that ?

Help me also how to terminate my app.

Imposible to call bass_free, i get a "illegal handle error".

Also imposible to terminate without error message (i try application.terminate, form.close, ...  always the same result...)

[DanaPaul]

Thanks, but why now, i never get error, do you add that ?

Ummm, (choke) yes.  I find it easier to build code with a bit of error checking rather than ignoring result errors and looking for problems in the wrong area.  However, since you have an existing app, you could comment this error checking statement in the header file.
 

Help me also how to terminate my app. Imposible to call bass_free, i get a "illegal handle error".

Well, that procedure doesn't pass any parameters to Bass.dll.  I suspect it has something to do with Bass internally.  Are you using BASS_STREAM_AUTOFREE?  Perhaps Ian can help with this one.

Also imposible to terminate without error message (i try application.terminate, form.close, ...  always the same result...)

I suspect this is somehow associated with "illegal handle error" when calling BASS_Free.  I'll try some testing to see if I can duplicate this BASS_Free error.

[DanaPaul]

Fred,

It is important that the following constant has a correct, and unique module name in your second BASS header file...

Code SelectExpand

implementation
const
  BassDll = 'bass2.dll' + #0;Also, the following methods should have unique identifiers...

Code SelectExpand

procedure Bass2DllLoad;
procedure UnloadBass2Dll;
function CheckBass2Version(dwVer: DWord): DWord;
function IsBass2DllLoaded: boolean;
implementation

[DanaPaul]

Fred,

After you have the second Bass header file cleaned up, consider removing all code from the Finalization sections of both Bass header files.

Apparently the reference counter that Windows API maintains for each mapped module isn't reliable (go figure).  I've changed the posted header files to maintain its own reference counter.  Your app is built solely around Bass so you don't need this functionality.  Removing this code from the Finalization section(s) will suit your purpose.

[fredvs]

Hi DannaPaul.

I have try your new bass_18.pas, it compile, program load, everything seems good, but when i do appliation.terminate, (everything goes well before :, bass_stop, bass_free, etc...) i get a error message : "inval handle" , i click OK then its ok, the app stop, without crash like in your past header.

This is better but...

NB: I dont have try already with your bass2.pas...

[fredvs]

Hi DanaPaul, its me again.

I have noted that the invalid handle message error comes only with application.terminate.

If i use mixk.close (mixk is the main form) instead, everyting goes well, the app terminate without crash.

I will try your bass2.pas...

[fredvs]

Hi DanaPaul

I have change and try bass2.pas, it seems to work.

But i have noted that now the mix and slide are not so fluently and i hear a litle crack at begining of play

Witch variable must i use to store getposition, now i use a comp variable, maybe it there the problem ?

NB I get sometimes the "invalid handle" error message while closing app, i have discard your error raising in your bass.pas for the moment, then no more error message...

[DanaPaul]

I have change and try bass2.pas, it seems to work. But i have noted that now the mix and slide are not so fluently and i hear a litle crack at begining of play

I'm assuming that Bass2.pas is simply a copy of Bass.pas to accomplish a second instance.  In that vein... download the latest header file. That was fixed.  Or, you can edit the (second) header file(s) yourself.  The problem is caused by a missed static binding statement "external".  That function is still loading Bass.dll at launch and binding with Bass.dll, not your second instance, Bass2.dll.

Mia Culpa

Witch variable must i use to store getposition, now i use a comp variable, maybe it there the problem ?

Bass is returning a QWORD, or COMP.

NB I get sometimes the "invalid handle" error message while closing app, i have discard your error raising in your bass.pas for the moment, then no more error message...

That has been fixed in the latest header file upload.

BTW, thank you for your Delphi 3 input

[fredvs]

Hi DP

Your header is perfect   and it help me to find some hidden bugs  

I have recompiled MixK with your header, the new version is on the download page.

Thanks a lot, nice job.

PS : Why have you do that, is it because you think Delphi 3 still the best and the more stable ?

[DanaPaul]

PS : Why have you do that, is it because you think Delphi 3 still the best and the more stable ?

I can't comment about Delphi 3 because I've used Delphi 2 since its initial release.  True, small footprint, fast, easily expandable.  But I think I have stayed with it today because I have no apparent need for the latest technologies, e-commerce, dot (what?) Net, etc.

Perhaps a 64 bit machine will change my attitude, eh?

[fredvs]

I switch between Delphi 2 and 3.
I work with Delphi since the begining (Delphi 1).

I agree totaly with your opinion.

[fredvs]

Hi DanaPaul

Thanks for your beautiful work.

With Delphi3, you use USE_64_ASM variable in place of built-in-false-64-bit COMP.

But you said also that to use it you must do a assembler procedure and that takes a litle time for the processor.

Perhaps it is a stupid question, but is i possible for your header to make the distinction of the valor > comp then use ASM else use COMP ? :-/

[DanaPaul]

Fred,

You want both? The ASM routines for full 64 bit precision and direct binding with Bass.dll using COMP (32 bit precision) for speed?

There are any number of ways to accomplish this.

1) If you don't want ASM 64 bit precision in the Multi Bass header files...

  A) Comment the conditional directives by placing a period after the leading bracket... {.$define USE_64_ASM}

  B) Undefine the directives after their definition ($undef USE_64_ASM}

  C) Define a directive of your own at the compiler options page named "SPEED_TEST" and place this in the header file after the original directives...
  {$ifdef SPEED_TEST}
    {$undef USE_64_ASM}
  {$endif SPEED_TEST}

2) If you want both methods, 64 bit ASM precision and direct (32 bit) binding with Bass.dll for speed then you could create identical functions under a slightly different name and then use GetProcAddress to bind these new functions...

BASS_ChannelSeconds2Bytes and FAST_ChannelSeconds2Bytes

BASS_ChannelGetPosition and FAST_ChannelGetPosition

BASS_StreamGetLength and FAST_StreamGetLength

In my humble opinion, this speed penalty is neglible. However, I plan to implement separate strategies with the Multi instance and Single instance Bass header files.  The Multi will have no error checking and bind directly with Bass(exception, these few functions mentioned above with D2 & D3). The single instance header files will have full error checking and (hopefully) become a good learning tool for Delphi/Bass.

[fredvs]

Whouaw   superb, they are lots of kings in those threads, it is exactly what i want...

Thanks a lot DP, i will dream of you this night (and of your codes of course)...

Very, very impressioned...

[DanaPaul]

BASS2_ChannelSetPosition ;
  
I get a BASS2_ERROR_POSITION : raise EBass2Exception.Create(sSeekPositionIllegal);

Ummm... found it Fred... A sporatic problem may exist if Windows blows away the registers that Delphi 2 and 3 use in GetPosition calls.  So if your SetPosition call was generating a new position based GetPosition then this could account for a sporatic seek error.

This has been fixed in the latest header file upload (today).  However, I am uploading a new (final) header file that will incorporate full error checking by raising plenty of exceptions.  Per chance you are not interested with trapping all of these Exceptions, I will save a copy of the header file that has the GetFilePosition fix before full error checking.  If you want a copy of this quick fix please let me know and I'll e-mail it to you.

[DanaPaul]

The single instance Bass header files have been optimized and now carry the last modification date annotated in the files.

http://members.aol.com/wtgdana/private/Bass/

These latest modifications include full error checking for Bass, BassWMA, and BassCD return results published in their respective help documentation.  The following validations are also included...

Float type outgoing and incoming parameter checking for possible NAN (not-a-number) errors.

LoadModule collision between BassWMA/BassCD, and additional validation that Bass is already loaded. Module names are checked in compliance with module naming conventions specified in the C+ header files.

These single instance header files are formatted to be as interchangeable as possible with the multiple instance header files already posted.

No further update notifications will be posted in this forum.  However, all bugs should continue to be reported