Hi 

is there any chance to get a pre-release that would fix this specific bug in a shorter time ? 

Kind Regards 

Nadia

Hi

Working on it
I believe that by the end of this month it will be ready.

Also a note, there will be an API changes in DSP definitions and structures and BPM functions (BASS_FX_BPM_Translate is removed)...
I might also remove BASS_FX_BPM_BeatDecodeGet function, as all of it content could be done pretty easily by a user and if I'll remove it, then all of it content will be added to BPM example (not decided yet)

It will be 2.4.10, but with changes I've planned for 2.5

[BASS_FX_BPM_BeatDecodeGet]

Hi 

thanks for confirming my doubts: do you have a time frame about the next release ?

Kind Regards 

Nadia

Hi

You're right!
I see that there indeed were some changes in BASS_FX_BPM_BeatDecodeGet function... and now you can't set parameters for decoding detection, because channel handle is freed

It will be fixed in next release

btw, chan means for decoding channel and handle is for both

Hello 

I think that I've found a regression in versions 2.4.8 and 2.4.9 of BASS_FX respect to version 2.4.7.

Calls to the BASS_FX_BPM_BeatSetParameters function seem to always return FALSE and parameters are not acccepted; BASS_ErrorGetCode returns error 5; this is very strange because a subsequent call to the BASS_FX_BPM_BeatDecodeGet function works as expected and will not return any error but, obviously, will work with its default parameters. The passed stream handle, which is a decoding channel, should be OK or it should fail as well.

Any idea? As mentioned, with version 2.4.7 the problem doesn't happen so it's likely that something changed.... 

As a second matter, looking at the documentation and at the header file, I've noticed that the first parameter of the BASS_FX_BPM_BeatDecodeGet function is named "chan" while for other "beat" related functions the first parameter is named "handle": am I right in assuming that they always mean the same thing?

Kind Regards 

Nadia

Hello Ian 

I think to have found the nature of the issue and it seems to be quite interesting: with the Terratec driver, you can check supported rates when the device is started and also when the device is not started; with the M-Audio Delta driver you can check supported rates only when the device is NOT started: when the M-Audio is started, it will only report the currently selected rate which will also result locked, meaning that also from the control panel it will be impossible changing the rate manually: being the rate locked, this should explain why it won't report other rates as supported.

Hope this could help others facing the issue. 

Best regards 

Nadia

Yes, it definitely works that way but only with this sound card because the Terratec one reports all of the supported rates; for testing I've made a loop from 4000 to 96000 calling the BASS_ASIO_CheckRate function for each iteration. The only rate reported as supported is the one set into the control panel: really strange. 

Hello Ian 

I've tried to change the rate programmatically using the BASS_ASIO_SetRate function and the change worked like a charm and was immediately reflected inside the control panel of the card so it doesn't seem that the driver is locking the rate.

Best Regards 

Nadia

Hello  

I was playing with the latest version of BassASIO under WIndows 7 32 bits and I noticed a problem which I cannot understand if related to the driver or to BassASIO missing something.

If I check the supported rates with a Terratec Aureon card, all of the 13 rates supported by the driver (and displayed by the card's control panel) are correct.

If I do the same with a M-Audio Delta 1010LT, whose control panel reports supporting 12 rates, the only reported rate is the one selected inside the control panel itself: if I set 44100 inside the control panel and use BASS_ASIO_CheckRate with other rates, only 44100 is reported as being supported; if I change to 48000 inside the control panel, 44100 is no more reported as supported by BASS_ASIO_CheckRate but 48000 does.

Are you aware of some limitation inside the M-Audio driver?

Kind Regards  

Nadia

Thanks a lot Ian 

Hello 

I have a piece of software that creates PCM audio streams in several formats, including 24 and 32 bits PCM (not in floating point); I would like to create a push stream using the BASS_StreamCreate function with the STREAMPROC_PUSH flag.
From the documentation it seems that the BASS_StreamCreate function can manage 8, 16 and 32 bits (floating point) streams: which is the correct way to manage a push stream fed with 24 or 32 bits streams? Do I need to convert the incoming samples from this resolution to, for example, floating point before sending them to the push stream or is there some other approach?

Thanks in advance and Kind regards 

Nadia

Hello Ian, 

I've found an issue inside the speakers.c source code, at least with the sound card of my desktop PC (Win 7, x86, Via High Definition Audio): in this code WASAPI is initialized in exclusive mode using the following code:

BASS_WASAPI_Init(-1,-1,-1,BASS_WASAPI_AUTOFORMAT|BASS_WASAPI_EXCLUSIVE,0.4,0.05,WasapiProc,NULL))

this call will always fail with error -1 returned by BASS_ErrorGetCode. If I remove the BASS_WASAPI_AUTOFORMAT flag the returned error value is 6. May be that the correct call should be the following?

BASS_WASAPI_Init(-1,0,0,BASS_WASAPI_AUTOFORMAT|BASS_WASAPI_EXCLUSIVE,0.4,0.05,WasapiProc,NULL))

Looking at your documentation I cannot see any reference to the fact that "freq" and "chans" parameters of BASS_WASAPI_Init could be set to -1 so it's likely that there is a small bug inside the sample. I thought it was worth to report.

Kind Regards 

Nadia

Hello Ian, 

the last version you released should be in any case more than enough for most purposes and users.

Well done 

Nadia

Yep, that could be useful information for the user to have, so an update for it is now up in the 1st post. I don't suppose it makes a big difference, as the other state can be inferred, but I couldn't really decide whether it was better to have a BASS_DEVICE_DISABLED flag (for DEVICE_STATE_DISABLED) or a BASS_DEVICE_NOTPRESENT flag (for DEVICE_STATE_NOTPRESENT). In the end I decided on BASS_DEVICE_DISABLED. Let me know if you think it was the wrong choice

Hello Ian  

from a design perspective in my opinion it would be better keeping the two states ("not present" and "disabled") separated because they mean two different things. As a side note, at a first glance the presence on the same mask of the BASS_DEVICE_ENABLED and BASS_DEVICE_DISABLED flags appears to be a bit misleading: may I suggest to change the original BASS_DEVICE_ENABLED flag to BASS_DEVICE_ACTIVE as seen inside the CoreAudio documentation? In this way there would be no confusion with devices disabled through the control panel.

Kind Regards  

Nadia

Hello,  

I'm starting to play with WASAPI and I've begun to see how to list available devices.

Due to the fact that BassWasapi is still listed as a beta, may I suggest to add the flags BASS_DEVICE_UNPLUGGED and BASS_DEVICE_NOTPRESENT to the "flags" parameter of the BASS_WASAPI_DEVICEINFO structure? In this way it would be possible to discriminate when a certain device, tipically USB devices, has been installed on the system but unplugged from the PC.
The difference between unplugged and not present is described on MSDN:
http://msdn.microsoft.com/en-us/library/windows/desktop/dd370823(v=vs.85).aspx

I don't know how BassWasapi enumerates endpoints but, as far as I know, the IMMDeviceEnumerator::EnumAudioEndpoints function of CoreAudio APIs allows the possibility to discriminate the situation.

Eventually, as an alternative, it could be also a good option, through the usage of a state mask, to avoid listing devices that are unplugged or not present.

Kind Regards  

Nadia

Hello 

I have some problem in understanding how BASS_FX calculates the value returned by the BASS_FX_TempoGetRateRatio function when both BASS_ATTRIB_TEMPO and BASS_ATTRIB_TEMPO_FREQ attributes are changed.

Suppose that I raise the BASS_ATTRIB_TEMPO_FREQ attribute of a 44100 song of 20%: after applying the new frequency the BASS_FX_TempoGetRateRatio function will return 1.20: so far so good.
If I now lower the BASS_ATTRIB_TEMPO attribute of 20% I would expect that this would compensate the previous change and that the BASS_FX_TempoGetRateRatio function would return 1.0 while it will return 0.96 : which is the reason of this discrepancy?

Thanks and Kind Regards 

Nadia

Hello 

I know that when a stream has been created through the BASS_StreamCreate having the STREAMPROC_DUMMY flag set, it will be possible to apply FX and DSP effects to an audio buffer through the BASS_ChannelGetData function. I was wondering if in the same situation it would be possible to calculate FFT data of the audio buffer using the same call to the BASS_ChannelGetData function and the appropriate flag (for example BASS_DATA_FFT2048).

If this shouldn't be possible, which would be the fastest solution to calculate the corresponding FFT on the audio buffer?

Thanks and Happy 2012 

Nadia

Hello 

I was wondering which is the slope (rolloff) applied to the limit of equalizer bands applied using the BASS_ChannelSetFX function: in most hardware products this is usually 12 dB per octave so I was wondering if the BASS_FX_BFX_PEAKEQ effect uses the same or if it's different. Looking at the BASS_BFX_PEAKEQ structure it doesn't seem to be configurable so I suspect that this is a fixed value: is this correct?

Thanks and Kind Regards 

Nadia

Hello 

the BASS_MIDI_StreamGetEvents function has a filter parameter which, when set to 0, allows retrieving all types of MIDI events from a MIDI stream.
Is there the possibility to do the same when setting the BASS_SYNC_MIDI_EVENT sync so, for each MIDI event occurring, the sync function is invoked? From the documentation it doesn't seem to be possible but it could be probably useful.

Kind Regards 

Nadia

Hello Ian 

I confirm you that this version fixes the issue.

Thanks and Kind Regards 

Nadia

I can't find the post right now, but I do recall that there was a problem found with BASS_MIDI_StreamEvents in BASS_MIDI_EVENTS_STRUCT mode, whereby the 1st event would be applied repeatedly in place of the other provided events. Please give the latest BASSMIDI build a try and let me know if you still have the problem with it...

   www.un4seen.com/stuff/bassmidi.dll

A new BASSMIDI release to make this fix (and other recent additions) official should appear later this month.

Hello  

there must be something wrong with the BASS_MIDI_StreamEvents function when used with the "mode" parameter set to BASS_MIDI_EVENTS_STRUCT: if you copy and paste the code available inside the documentation, only the first note (60) seems to be played (and with higher energy as the 3 notes should be always 60) while the other 2 notes appear to be ignored.

No problem when the "mode" parameter is set to BASS_MIDI_EVENTS_RAW.

I'm using verison 2.4.6.3 of Bass_midi: is this a bug or is some setting missing inside the documentation's code?

Kind Regards  

Nadia

Hello 

on my Windows 7 PC, while playing a sound through the default sound card, if I disable this sound card from the control panel the status reported by the  BASS_ChannelIsActive function immediately goes from BASS_ACTIVE_PLAYING to BASS_ACTIVE_STOPPED.
I was wondering if there is a way or a sync to be informed that playback was stopped due to the output device becoming unavailable.

Kind Regards 

Nadia