20 Jun '13 - 10:04 *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
 
   Home   Help Search Login Register  
Pages: 1 [2]  All
  Reply  |  Print  
Author Topic: Determine level in RecordProc via ChannelGetLevel or buffer?  (Read 9705 times)
Sebastian Andersson
Posts: 372


« Reply #20 on: 15 Jan '06 - 19:17 »
Reply with quoteQuote

You basically put this in the EncodeProc (assuming you've setup an encoder on the recording channel):

If maxR > 20000 Then
    BASS_Encode_Write chan, buffer, length
End If

VolumeProc = BASSTRUE ' This is necessary to continue recording

Note that I used the BASS_ENCODE_PAUSE flag in my BASS_Encode_Start call (when testing this).
Logged
tmighty
Posts: 27


« Reply #21 on: 15 Jan '06 - 20:24 »
Reply with quoteQuote

Talking about RECORDPROC....
do you really mean
VolumeProc = BASSTRUE ' This is necessary to continue recording

or
RECORDPROC = BASSTRUE ' This is necessary to continue recording
?
Knowing that will assumably prevent me from more mistakes.
For the 1000. times: Thank you!

Logged
Sebastian Andersson
Posts: 372


« Reply #22 on: 15 Jan '06 - 20:33 »
Reply with quoteQuote

Yes, I meant "RecordProc". I've just renamed the one in my example to "VolumeProc".
« Last Edit: 15 Jan '06 - 20:42 by Sebastian Andersson » Logged
tmighty
Posts: 27


« Reply #23 on: 16 Jan '06 - 11:28 »
Reply with quoteQuote

.
« Last Edit: 16 Jan '06 - 14:23 by tmighty » Logged
Sebastian Andersson
Posts: 372


« Reply #24 on: 16 Jan '06 - 14:24 »
Reply with quoteQuote

If I want to display the spectrum even while encoding, can I use the recording "chan" also to encode?

It worked in my example, so I guess you can.

Why is the encoding working with streams? I know it's only a FreeStream command, but anyway I would to know why this is done:
    'free old recording
    If (chan) Then
        Call BASS_StreamFree(chan)
        chan = 0
        MainForm.btnPlay.Enabled = False
    End If
Why is it saying:
Call BASS_StreamFree(chan)

and not
Call BASS_Free(chan)
Huh

BASS_StreamFree is used to free the resources (memory etc) for a particular stream. BASS_Free is used to free all resources within BASS, that is, all streams (and the memory they allocate), the device initialized and anything else that has been created by BASS. BASS_Free should only be called when an application is about to close. BASS_Free doesn't require any parameter, by the way.

And why would you start encoding directly in RECORDPROC (or VOLUMEPROC) and not just call a function which starts the encoding. I thought that RECORDPROC has to be quick.

I'm pretty much doing what Ian does in the link he posted, I start a paused encoder on the recording channel, and if the threshold level has been reached in the RecordProc, I simply (manually) write the sample data to the encoder - it's fairly quick and simple. There are of course other methods, but this one does the job.
Logged
tmighty
Posts: 27


« Reply #25 on: 16 Jan '06 - 14:34 »
Reply with quoteQuote

Okay, I think I'm starting to understand this. I must admit I went into this with wrong ideas of how easy it is. Or maybe it's just complicated for a bass newbie like me.
Could you post the code of how you start the encoding in pause mode? If it's in the sample apps then I am blind. I know I could figure it out in 1 hour from the manual, but if you have it already then it would be nice of you to post it for me (and maybe all VBlers who read this post because they are struggeling with the same problem).
Thanks for the time you spent here!
TM.

(Sorry I delete my last post, because I thought it was stupid).

One more thing:
Is that correct? ->
The good thing about the RecordProc is that is it being automatically fired when the buffer (lets say sound buffer of 5 ms) is full. And in the RecordProc we can check the level/ volume of the buffer. So this is why it's better than a timer which fires not often detect to e.g. detect a high level early enough to detect the first letter of a spoken word.
But when we check the volume in the RecordProc we can be sure that me are missing nothing! And we can even send that FIRST buffer (that has a high level) directly to the Encoding_Start, right? And this first buffer is not abandoned but directly send to the buffer. Because we do not say "Start the encoding now and record anything as soon as you are ready", but we say "Start the encoding with this buffer!".
Correct?
« Last Edit: 16 Jan '06 - 14:43 by tmighty » Logged
Sebastian Andersson
Posts: 372


« Reply #26 on: 16 Jan '06 - 15:01 »
Reply with quoteQuote

I've reuploaded my example application (same link as before).

Thanks for the time you spent here!

No worries. Smiley

Is that correct? ->
The good thing about the RecordProc is that is it being automatically fired when the buffer (lets say sound buffer of 5 ms) is full. And in the RecordProc we can check the level/ volume of the buffer. So this is why it's better than a timer which fires not often detect to e.g. detect a high level early enough to detect the first letter of a spoken word.
But when we check the volume in the RecordProc we can be sure that me are missing nothing! And we can even send that FIRST buffer (that has a high level) directly to the Encoding_Start, right? And this first buffer is not abandoned but directly send to the buffer. Because we do not say "Start the encoding now and record anything as soon as you are ready", but we say "Start the encoding with this buffer!".
Correct?

Yes. I'd call it "Initialize the encoding and write whenever threshold>=N" though.
Logged
tmighty
Posts: 27


« Reply #27 on: 16 Jan '06 - 18:41 »
Reply with quoteQuote

It all works fine now, looking at the encoding and the callbacks.
But I have encountered a serious problem which has to do with VB, I think.
There is a serious memory read error when I move my mouse, simply as that.
I do believe that this is the feared CallbackSafety problem...
And the SafeCallBack.dll doesn't help me, because I can't use the real callback anymore.  And I can only use safecallback with a timer which is a good as nothing.
I could have easily done all my work before with a timer and WITHOUT a safecallback, I guess.
So there is no point for me to try to work with the callbacks anymore because of the stupidity of VisualBasic.
That's right, isn't it? Or what else could it be that every time I do something that's a bit heavy for a computer (like moving a mouse pointer LOL  Cry) it crashes.
It's true isn't it... tell me it's not VB... PLEASE!!! Just tell me that's doing a mega mistake somewhere....

My code in the CallBack is:
Public Function RECORDPROC(ByVal handle As Long, ByVal buffer As Long, ByVal length As Long, ByVal user As Long) As Long

iLevel = LoWord(BASS_ChannelGetLevel(Chan)) 'check the record level

If bEncoderLoaded = True Then
            BASS_Encode_Write! handle, buffer, length
End If
End Function

TM.
Logged
Sebastian Andersson
Posts: 372


« Reply #28 on: 16 Jan '06 - 18:51 »
Reply with quoteQuote

My code in the CallBack is:
Public Function RECORDPROC(ByVal handle As Long, ByVal buffer As Long, ByVal length As Long, ByVal user As Long) As Long

iLevel = LoWord(BASS_ChannelGetLevel(Chan)) 'check the record level

If bEncoderLoaded = True Then
            BASS_Encode_Write! handle, buffer, length
End If
End Function

TM.

I guess the exclamation mark after BASS_Encode_Write is a typo? Anyway, you're missing the "RECORDPROC = BASSTRUE" again. Without it, BASS won't continue recording. I've not tested the SafeCallback system, so I can't really tell - but I've used callbacks in VB before, and it's all went good. Also, you probably should use the "handle" parameter in the RECORDPROC (not the "Chan" global variable):

Public Function RECORDPROC(ByVal handle As Long, ByVal buffer As Long, ByVal length As Long, ByVal user As Long) As Long

iLevel = LoWord(BASS_ChannelGetLevel(handle)) 'check the record level

If bEncoderLoaded = True Then
            BASS_Encode_Write handle, buffer, length
End If

RECORDPROC = BASSTRUE

End Function
Logged
tmighty
Posts: 27


« Reply #29 on: 16 Jan '06 - 21:09 »
Reply with quoteQuote

Hi again,
I had the RECORDPROC in my code, sorry I didn't type it in my posting.
I have changed the "(chan)" to "handle". Seems to crash less frequently...
But I have to do some more tests... thanks so far, thanks very much!
TM.
Logged
tmighty
Posts: 27


« Reply #30 on: 17 Jan '06 - 10:48 »
Reply with quoteQuote

I am totally amazed, it works. It really works without crashes WITH callbacks in VISUALBASIC (just to state that to any further VB-Programmers who are about to go crazy). I have fuddled a lot with variables, now my code looks like a dust bin. But I am going to clean it up and post it.
 Grin Grin Grin Grin Grin
Logged
Pages: 1 [2]  All
  Reply  |  Print  
 
Jump to:  

Powered by SMF 1.1.18 | SMF © 2013, Simple Machines