Olaf, Jim, et al, I think I've cracked it by defining midiOutShortMsg in a typelib ! 
Author Message
 Olaf, Jim, et al, I think I've cracked it by defining midiOutShortMsg in a typelib !

I have definitely narrowed down the cause of the GPF in the compiled
version of my MIDITimerTest project. I finally commented out
EVERYthing in the PlaybackEngine (i.e. the Timer callback), then line
by line removed the comments, recompiling and testing for each
uncommented line.

I found that I could uncomment more and more and the GPF did not
occur. Then I was left with just this commented out line:

' midiOutShortMsg g_MIDI_Out, midiMsg

****************************************************************************************
As soon as I uncommented THIS line and recompiled, the GPF occurred.
****************************************************************************************

Then I remember what MSDN says about only permitting very few calls
inside a multimedia Timer callback. Now, although midiOutShortMsg *IS*
one of those permitted calls, I then pondered what Olaf, Karl, Jim and
others said about inadvertently causing the VB runtime to be invoked
during the Timer callback - and then I had a brainwave!

I commented out the Declare Function midiOutShortMsg blurb in the
General Declarations section and replaced it with a typelib I
downloaded from a forum. The additional typelib defines
midiOutShortMsg.

As soon as I referenced this additional typelib and recompiled, the
GPF stopped occurring, I can hear my MIDI test piece and I can move
the form as it is playing without interrupting the flow. And
PostMessage works, too.

Phew!

MM



Thu, 05 Jan 2012 01:20:15 GMT  
 Olaf, Jim, et al, I think I've cracked it by defining midiOutShortMsg in a typelib !



Quote:
> I commented out the Declare Function midiOutShortMsg blurb
> in the General Declarations section and replaced it with a typelib
> I downloaded from a forum. The additional typelib defines
> midiOutShortMsg.

> As soon as I referenced this additional typelib and recompiled, the
> GPF stopped occurring, I can hear my MIDI test piece and I can
> move the form as it is playing without interrupting the flow.

Glad you've finally found that out yourself.
I would nonetheless *not* work in that way (no matter, if that
currently works in the IDE or in your compiled binary), since
you're doing "a lot of things" in addition to the plain typelib-
defined calls there - I'd strongly recommend, to use only
the PostMessage-approach (with only that one single line
in the callback-procedure), to be able to work in a very
stable way within your IDE and also in your exe - the
(decoupling) posted message is later on received on your
MainThread - and on that MainThread everything else
is then allowed again (raising errors and Events, accessing
Objects etc.) - all that would be a tabu, if you decide to work
further with your "whole playback-engine, running on an
uninitialized thread" (not having a proper, VB-conform TLS-init).

Please take a look at the following, which is based on your
posted minimal-example. I've reorganized a bit - and changed
the timing-calculation to an absolute one (based on timeGetTime) -
involving the OneShot-MMTimer-approach again - and avoiding
also the SubClassing-Code.
Also moved your PlayBack-Engine into a Class (cMStream),
which does not work with globally defined MIDIEvent-Arrays
anymore, but with local ones instead.
So the Demo is now able, to play two (or more) Streams
independently (in parallel).

Just take a look - maybe you can incorporate some ideas
into your larger RealWorld-project...

www.datenhaus.de/Downloads/MidiStreaming.zip

Olaf



Fri, 06 Jan 2012 03:13:16 GMT  
 Olaf, Jim, et al, I think I've cracked it by defining midiOutShortMsg in a typelib !

Quote:



>> I commented out the Declare Function midiOutShortMsg blurb
>> in the General Declarations section and replaced it with a typelib
>> I downloaded from a forum. The additional typelib defines
>> midiOutShortMsg.

>> As soon as I referenced this additional typelib and recompiled, the
>> GPF stopped occurring, I can hear my MIDI test piece and I can
>> move the form as it is playing without interrupting the flow.

>Glad you've finally found that out yourself.
>I would nonetheless *not* work in that way (no matter, if that
>currently works in the IDE or in your compiled binary), since
>you're doing "a lot of things" in addition to the plain typelib-
>defined calls there - I'd strongly recommend, to use only
>the PostMessage-approach (with only that one single line
>in the callback-procedure), to be able to work in a very
>stable way within your IDE and also in your exe - the
>(decoupling) posted message is later on received on your
>MainThread - and on that MainThread everything else
>is then allowed again (raising errors and Events, accessing
>Objects etc.) - all that would be a tabu, if you decide to work
>further with your "whole playback-engine, running on an
>uninitialized thread" (not having a proper, VB-conform TLS-init).

>Please take a look at the following, which is based on your
>posted minimal-example. I've reorganized a bit - and changed
>the timing-calculation to an absolute one (based on timeGetTime) -
>involving the OneShot-MMTimer-approach again - and avoiding
>also the SubClassing-Code.
>Also moved your PlayBack-Engine into a Class (cMStream),
>which does not work with globally defined MIDIEvent-Arrays
>anymore, but with local ones instead.
>So the Demo is now able, to play two (or more) Streams
>independently (in parallel).

>Just take a look - maybe you can incorporate some ideas
>into your larger RealWorld-project...

>www.datenhaus.de/Downloads/MidiStreaming.zip

>Olaf

Thanks very much, Olaf. However, there is one fundamental problem with
your mod and that is when I move the form while the streaming is in
progress, the streaming freezes. This is the fundamental problem that
I set out to fix a few weeks ago. The streaming (sound output) *must*
continue, no matter what the user happens to be doing with the
form(s).

MM



Fri, 06 Jan 2012 14:39:50 GMT  
 Olaf, Jim, et al, I think I've cracked it by defining midiOutShortMsg in a typelib !



Quote:
> Thanks very much, Olaf. However, there is one fundamental
> problem with your mod and that is when I move the form
> while the streaming is in progress, the streaming freezes.

Did you tried it?

No such thing happens here - two streams playing - whilst
dragging the form around - or resizing the form.

Quote:
> This is the fundamental problem that I set out to fix a few
> weeks ago.

I know - and that's why I wrote the OneShot-based
alternative - especially for Win98, since normal (PostMessage-
based, continously firing MMTimers are able to flood the
Win98-Messagequeue up to a real program-freeze.
This cannot happen with oneshots.

Quote:
> The streaming (sound output) *must* continue, no matter
> what the user happens to be doing with the form(s).

No matter is a bit strict - and only solvable by a real
(fully) threaded decoupling - which the PostMessage-based
MMTimer-approaches cannot achieve.

Your direct working within the MMTimer-callback-proc
already *is* multithreading - but as it is currently, not on
a very stable fundament, since you have not initialized
VBs-TLS - and initializing it is a (relative) expensive
task, not suitable to perform every now and then
in a callback that comes in - every few msec.

The PostMessage-based approaches, (be it the
OneShot-ones - ore the Continous-ones) already
decouple from that uninitialized thread nicely - but
you end up, running your incoming timer-events
(posted messages)  in a single thread again  -
and as soon as you perform GUI-refresh-actions,
which take longer than the interval to your next Note,
then you will hear, that this next note is played in
delay (after your parallel GUI-action is finished).

In my current example the parallel GUI-interactions
I've tested (dragging the form around, resizing,
adding listview-entries) whilst streams were playing,
didn't cause such long enough "lags" - at least here on my
machine on XP. But more expensive GUI-refresh-
actions, which take longer than e.g. 20-40msec could
cause a lag, if these gui-timeouts "overlap" long enough
with the "next Notes-Delta-time"...

But please at least check out the new demo - I've invested
some efforts into that - and this time I've based the whole
thing mainly on your engine-code - should be familiar to
you all that.

Olaf



Fri, 06 Jan 2012 18:23:04 GMT  
 Olaf, Jim, et al, I think I've cracked it by defining midiOutShortMsg in a typelib !

Quote:



>> Thanks very much, Olaf. However, there is one fundamental
>> problem with your mod and that is when I move the form
>> while the streaming is in progress, the streaming freezes.
>Did you tried it?

Yep. Both in the IDE and compiled. On 98SE. I'll try it later on a
post-98SE platform as well.

Quote:

>No such thing happens here - two streams playing - whilst
>dragging the form around - or resizing the form.

On 98SE as soon as I hold the mouse down ready to move the form (IDE
or .exe) the playback stops.

Quote:

>> This is the fundamental problem that I set out to fix a few
>> weeks ago.
>I know - and that's why I wrote the OneShot-based
>alternative - especially for Win98, since normal (PostMessage-
>based, continously firing MMTimers are able to flood the
>Win98-Messagequeue up to a real program-freeze.
>This cannot happen with oneshots.

>> The streaming (sound output) *must* continue, no matter
>> what the user happens to be doing with the form(s).
>No matter is a bit strict - and only solvable by a real
>(fully) threaded decoupling - which the PostMessage-based
>MMTimer-approaches cannot achieve.

I can achieve it with Paul Messick's Maximum MIDI code DLL. He even
gives a VB5 example which works fine.

HOWEVER! (anothe b-i-g however...) his timer proc calls back to the
main app ONLY to send a beat counter, which is of no use to me. I need
to know the note number and on/off data. Also, his routines play ONLY
the complete MIDI file, whereas I want to play only part, or only
above MIDI note number 60 (for example).

Already I tried recompiling his C/C++ code in Borland C++, but I am
NOT a C programmer, so for me it's like digging a field with a
teaspoon. I figured, if I could at least get his code to compile
without errors, then I could start thinking about modifying it and
adding to it to do what I need. But I got so many errors it would take
me a month of Sundays to work through them all. I still haven't given
up going down that route, but when I did get my (simplifed) version of
his playback engine (which he calls "Sync handler") working fine in VB
code, I thought, no worries, I've cracked it! Even on 98SE I can move
the form, scroll the flexgrid, whatever, and the sound happily
continues to play, as if I was using van Basco's Karaoke player or
running a MIDI file in VB through the MCI control.

Quote:
>Your direct working within the MMTimer-callback-proc
>already *is* multithreading - but as it is currently, not on
>a very stable fundament, since you have not initialized
>VBs-TLS - and initializing it is a (relative) expensive
>task, not suitable to perform every now and then
>in a callback that comes in - every few msec.

But with midiOutShortMsg it now works reliably in the .exe, so what
would I need to do to make it more stable? What initialising (of TLS)
are you thinking of here? Note that I am not working at 1msec but at
10msec. Also, I exit the playback engine immediately if it is already
busy.

Quote:
>The PostMessage-based approaches, (be it the
>OneShot-ones - ore the Continous-ones) already
>decouple from that uninitialized thread nicely - but
>you end up, running your incoming timer-events
>(posted messages)  in a single thread again  -
>and as soon as you perform GUI-refresh-actions,
>which take longer than the interval to your next Note,
>then you will hear, that this next note is played in
>delay (after your parallel GUI-action is finished).

Yep and any delay is what needs to be avoided.

Quote:
>In my current example the parallel GUI-interactions
>I've tested (dragging the form around, resizing,
>adding listview-entries) whilst streams were playing,
>didn't cause such long enough "lags" - at least here on my
>machine on XP. But more expensive GUI-refresh-
>actions, which take longer than e.g. 20-40msec could
>cause a lag, if these gui-timeouts "overlap" long enough
>with the "next Notes-Delta-time"...

>But please at least check out the new demo - I've invested
>some efforts into that - and this time I've based the whole
>thing mainly on your engine-code - should be familiar to
>you all that.

Yes, I do appreciate all your efforts and you must have invested some
time in producing the new demo, all of which is greatly appreciated.
None of it goes to waste, because it is, as we say, all grist to the
mill and I am continuing to learn new stuff about threading and
suchlike. For example, that sudden "brainwave" I had over sticking
midiOutShortMsg in a typelib, well, three or four weeks ago, when all
this started, I would not have had a CLUE what this would all mean! I
was barely aware of the existence of typelibs, since I've never needed
to find out about them. All your input and that from the others has
been MOST valuable and I am very grateful for it.

I have read through the new demo code extensively already this morning
and have run it in the IDE and compiled and run it on 98SE. Later
today I'll also try it on XP.

Cheers!

MM



Fri, 06 Jan 2012 19:28:46 GMT  
 Olaf, Jim, et al, I think I've cracked it by defining midiOutShortMsg in a typelib !

Quote:

>................- all that would be a tabu, if you decide to work
>further with your "whole playback-engine, running on an
>uninitialized thread" (not having a proper, VB-conform TLS-init).

I'd be quite prepared to rewrite the playback engine in C or Delphi
(Pascal) if that's what it takes to get thread (?) stability. I can
call Messick's Maximum MIDI code (DLL) from VB, but it doesn't do
entirely what I want (see further posts from me a few minutes ago).

MM



Fri, 06 Jan 2012 19:32:55 GMT  
 Olaf, Jim, et al, I think I've cracked it by defining midiOutShortMsg in a typelib !



Quote:
> On 98SE as soon as I hold the mouse down ready to
> move the form (IDE or .exe) the playback stops.

Yep - I know that effect on Win98 - holding down the
mousekey on a windows caption entirely stops every
message-receiving - in fact Win98 enters an "endless-loop"
in that case, if you look at the taskmanager for example -
processor-load is then 100%.

On XP this "blocking, whilst holding down the mousekey
on a caption" is also there - but XP skips that blocking
after about 100-200msec - and in either case that blocking
loop is immediately exited (also on Win98), as soon as you
start dragging the window around.

No way around that with a single threaded App (other than to
replace the original Window-Caption with your own creation) -
so, if you want to avoid exactly this special case (clicking the
caption and holding the mouse down), then there's no other
way than real threading - entirely decoupling from your main-
GUI-thread then.

The new Demo is nonetheless able, to "play fairly well"
(in parallel to other GUI-interaction, as dragging, resizing,
refreshing other Controls) - which was not able
with your older singlethreaded approach - involving
DoEvents, which caused some problems due to their
acting as a "GUI-Event-BlackHole". At least that
is now solved - no DoEvents anymore in the code.

Olaf



Fri, 06 Jan 2012 21:08:33 GMT  
 Olaf, Jim, et al, I think I've cracked it by defining midiOutShortMsg in a typelib !



Quote:

> >................- all that would be a tabu, if you decide to work
> >further with your "whole playback-engine, running on an
> >uninitialized thread" (not having a proper, VB-conform TLS-init).

> I'd be quite prepared to rewrite the playback engine in C or Delphi
> (Pascal) if that's what it takes to get thread (?) stability. I can
> call Messick's Maximum MIDI code (DLL) from VB, but it doesn't do
> entirely what I want (see further posts from me a few minutes ago).

In case you want to use the small DirectCOM.dll fom my toolset,
then you can also place your engine within a normal VB6-Activex-
Dll - running the class then on a separate thread.
That is the toolsets Low-Level-Treadhelper.

There's also an easier to use high-level threading - but if you
want to use that, you would have to redistribute not only
DirectCOM.dll (~20kB), but the "full redist" of my
helperlibs (3 Dlls then, taking up about 860kByte of
DiskSpace).
In either case no registering would be required.

Another way would be, if you are willing to change your Main-
App (currently a Standard-Exe) to an Activex.exe-project.

In all cases you can write your threaded code entirely with VB6.

Let me know, which way you want to go - but also Freebasic
for example would worth a look, the syntax is not all that
different from VB, especially since you're apparently not
accessing any VB-Objects in your Play-Loop.

Olaf



Fri, 06 Jan 2012 21:18:13 GMT  
 Olaf, Jim, et al, I think I've cracked it by defining midiOutShortMsg in a typelib !

Quote:




>> >................- all that would be a tabu, if you decide to work
>> >further with your "whole playback-engine, running on an
>> >uninitialized thread" (not having a proper, VB-conform TLS-init).

>> I'd be quite prepared to rewrite the playback engine in C or Delphi
>> (Pascal) if that's what it takes to get thread (?) stability. I can
>> call Messick's Maximum MIDI code (DLL) from VB, but it doesn't do
>> entirely what I want (see further posts from me a few minutes ago).

>In case you want to use the small DirectCOM.dll fom my toolset,
>then you can also place your engine within a normal VB6-Activex-
>Dll - running the class then on a separate thread.
>That is the toolsets Low-Level-Treadhelper.

I downloaded the DirectCOMDemo months ago, but couldn't make head nor
tail of it. I've just taken another look and I still don't have a clue
what it's doing or why.  Your website is undergoing maintenance at the
moment, so I can't check to see whether there's any documentation I
might have missed the last time. I'll check back there in a few days'
time.

MM



Sat, 07 Jan 2012 02:54:14 GMT  
 Olaf, Jim, et al, I think I've cracked it by defining midiOutShortMsg in a typelib !

Quote:





>>> >................- all that would be a tabu, if you decide to work
>>> >further with your "whole playback-engine, running on an
>>> >uninitialized thread" (not having a proper, VB-conform TLS-init).

>>> I'd be quite prepared to rewrite the playback engine in C or Delphi
>>> (Pascal) if that's what it takes to get thread (?) stability. I can
>>> call Messick's Maximum MIDI code (DLL) from VB, but it doesn't do
>>> entirely what I want (see further posts from me a few minutes ago).

>>In case you want to use the small DirectCOM.dll fom my toolset,
>>then you can also place your engine within a normal VB6-Activex-
>>Dll - running the class then on a separate thread.
>>That is the toolsets Low-Level-Treadhelper.

>I downloaded the DirectCOMDemo months ago, but couldn't make head nor
>tail of it. I've just taken another look and I still don't have a clue
>what it's doing or why.  Your website is undergoing maintenance at the
>moment, so I can't check to see whether there's any documentation I
>might have missed the last time. I'll check back there in a few days'
>time.

>MM

Scrub that last post. I've found http://www.thecommon.net/3.html
instead!

MM



Sat, 07 Jan 2012 02:58:39 GMT  
 Olaf, Jim, et al, I think I've cracked it by defining midiOutShortMsg in a typelib !



Quote:

> >In case you want to use the small DirectCOM.dll fom my toolset,
> >then you can also place your engine within a normal VB6-Activex-
> >Dll - running the class then on a separate thread.
> >That is the toolsets Low-Level-Treadhelper.

> I downloaded the DirectCOMDemo months ago, but couldn't
> make head nor tail of it.
> I've just taken another look and I still don't have a clue
> what it's doing or why.  Your website is undergoing maintenance
> at the moment, ...

Yeah, and that "moment" is already a quite long one (blush) -
but you already found the "tool-site" as I see it.

But careful, the low-level-threading support is not documented
nor covered within the current Demo-Set download.
It contains only a Demo for the highlevel threading-helper,
which is of no use to you, since it requires W2K or higher
to work (depending on pipes in message-mode).

Will see, that I add threading per DirectCOM.dll to the
Demo I've already built, based on your initial-example.

Will add some comments there, what to declare and use
from DirectCOMs exports, to startup an ActiveX-dll-
Class on its own thread.

Just give me some time for that...

Olaf



Sat, 07 Jan 2012 03:47:21 GMT  
 Olaf, Jim, et al, I think I've cracked it by defining midiOutShortMsg in a typelib !

Quote:




>> >In case you want to use the small DirectCOM.dll fom my toolset,
>> >then you can also place your engine within a normal VB6-Activex-
>> >Dll - running the class then on a separate thread.
>> >That is the toolsets Low-Level-Treadhelper.

>> I downloaded the DirectCOMDemo months ago, but couldn't
>> make head nor tail of it.
>> I've just taken another look and I still don't have a clue
>> what it's doing or why.  Your website is undergoing maintenance
>> at the moment, ...
>Yeah, and that "moment" is already a quite long one (blush) -
>but you already found the "tool-site" as I see it.

>But careful, the low-level-threading support is not documented
>nor covered within the current Demo-Set download.
>It contains only a Demo for the highlevel threading-helper,
>which is of no use to you, since it requires W2K or higher
>to work (depending on pipes in message-mode).

>Will see, that I add threading per DirectCOM.dll to the
>Demo I've already built, based on your initial-example.

>Will add some comments there, what to declare and use
>from DirectCOMs exports, to startup an ActiveX-dll-
>Class on its own thread.

>Just give me some time for that...

>Olaf

Okay, many thanks. Note that this is NOT an urgent project! After all,
I have the "DoEvents" version for folks to download if they wish (50
so far!). Plus, I still strongly believe that the vast majority of
users *won't* be moving the forms, scrolling the grid etc.

However, I would prefer a version that works the way I've described,
as possible (with limitations) via Messick's C/C++ Maximum MIDI DLL or
with even more limitations via the MCI control. The one key feature of
these, plus vanBasco's Karaoke and any sequencer/notation app
(Cakewalk, Finale, Sibelius etc) I've used is that the MIDI output
never stops when the app itself (its windows/controls/whatever) are
being  manipulated by the user.

The only "bitte" I would have is that your example is kept as simple
as possible, since most of this stuff is totally new to me. Bells and
whistles I can add later, once I understand the fundamental concept.

To give you some idea of where I'm at: I took another look at the
DirectCOM code: On a scale of 1 - 100 in terms of me comprehending it
I would place myself at 3. That is the mountain I have to climb. Think
of Everest, then put the Matterhorn on top...

In the meantime I am, of course, continuing to research threads, C,
Appleman, the VB6 Programmer's Guide Creating the Coffee Project
(ActiveX)... I never sleep! Well, only about 5 hours a night.

MM



Sat, 07 Jan 2012 04:45:39 GMT  
 Olaf, Jim, et al, I think I've cracked it by defining midiOutShortMsg in a typelib !



Quote:
> The only "bitte" I would have is that your example is kept as simple
> as possible, since most of this stuff is totally new to me. Bells and
> whistles I can add later, once I understand the fundamental concept.

Ok, done - please download from the same link:
www.datenhaus.de/Downloads/MidiStreaming.zip
(now including a SubFolder with the threaded approach).

Quote:
> To give you some idea of where I'm at: I took another look at the
> DirectCOM code: On a scale of 1 - 100 in terms of me comprehending
> it I would place myself at 3. That is the mountain I have to climb. Think
> of Everest, then put the Matterhorn on top...

Nah - if I count the needed changes from the already posted
approach with the OneShot-MMTimer (already having that
class-encapsulation of the Stream-engine) - the needed changes
for the threaded version sum up to only 10-20 lines difference.

Maybe a good idea, to fully understand at least the structures
in that simpler Demo first (it is yet contained in the *.zip),
before trying to find the similarities (and differences) in the
Threaded approach (contained in a SubFolder of the *.zip).

What you need to understand from DirectCOM.dll is only one
needed Declare (to startup the ThreadClass regfree) and one
ThreadInit-Type which you will have to place the UserData-Pointer
in, before passing it to the just mentioned StartCOMObject-call.

The thread is initiated from within the same MainApp-Class
you already know (cMStream), which now does not contain its
PlayStream-Routine anymore - this routine is now placed
(nearly unchanged) in the ThreadClass instead.
The already known "Message-Receiver-Form" is also yet there,
in the MainThread - but now not receiving the MMTimer-Messages
anymore, but Event-Notifications from the thread instead.

So, the Multimediatimer is gone (not needed anymore) - instead
we perform an appropriate loop with an interval of 1-2msec in the
thread-class's ThreadMain-Function itself (triggering your engine
repeatedly, directly from within that loop now...

Quote:
> In the meantime I am, of course, continuing to research threads, C,
> Appleman, the VB6 Programmer's Guide Creating the Coffee Project
> (ActiveX)... I never sleep! Well, only about 5 hours a night.

<g>...
Just ask if something is unclear - but I've tried, to write some
more comments, how everything "plays together"...

Olaf



Sat, 07 Jan 2012 09:34:28 GMT  
 Olaf, Jim, et al, I think I've cracked it by defining midiOutShortMsg in a typelib !

Quote:

>Just ask if something is unclear - but I've tried, to write some
>more comments, how everything "plays together"...

Okay. Many thanks for this. I've spent the morning reading the code
and trying to fix it in my head. You have to realise (Karl will
confirm!) that I have been very, VERY anti-OOP for decades, and this
example, while doubtless perfectly comprehensible to an OOP
enthusiast, only reinforces my fundamental hatred of OOP compared to
straightforward procedural programming. In OOP, the bits and pieces of
an app seem to be all over the place! Like trying to nail jelly to the
ceiling. This, naturally, leaves me feeling very frustrated. Still,
I'll keep banging away at it. Maybe I'll draw myself a few pictures.
That may help.

The first thing I wanted to do is replace the fMMt with a "proper"
WindowProc with its standard parameters iMsg, wParam, lParam because
it's too fiddly/messy working with a MouseMove event that is expecting
different parameters, especially as I want to call SendNotifyMessage
for other reasons. For example, if I have a WindowProc (based on
frmMessageWindow) I could set up a Select Case like this:

Function HiddenWindowProc(ByVal hwnd As Long, ByVal iMsg As Long, _
                           ByVal wParam As Long, ByVal lParam As Long)
As Long

   Dim Data1 As Byte 'the Note
   Dim Data2 As Byte 'the Velocity (in case of NoteOn)
   Dim Status As Byte 'the Statusbyte

    Select Case iMsg
      Case 5678 ' Note On/Off data
        Status = wParam And &HFF
        Data1 = (wParam \ 256) And 256
        Data2 = (wParam \ 256) \ 256
        If (Status = &H80) Or (Status = &H90 And Data2 = 0) Then
           Call NoteOff(Data)
        Else
           Call NoteOn(Data1, Data2)
        End If
      Case 5679
         Call DisplayNewTempo(lParam)
      Case 5680
         Call DisplayMIDIQueuePtr (lParam\256)
      Case 5681
         ' ....process some other kind of data, whatever
      Case Else
         CallWindowProc m_lOldWndProc, hwnd, iMsg, wParam, lParam
    End Select

End Function

In MidiStreaming's PlaybackEngine I want to do, for example:
SendNotifyMessage m.MMhWnd, 5678, midiMsg, 0
or SendNotifyMessage m.MMhWnd, 5679, newtempo, 0
or SendNotifyMessage m.MMhWnd, 5680, m.PlaybackPtr, 0
or whatever I might need later on.

However, I didn't get very far, since I discovered that I can't place
my WindowProc (from CreateMessageWindow) in MidiMain's cMStream.cls
because VB barfs at that and insists that AddressOf demands the proc
be in a standard module. And then I found that RaiseEvent doesn't work
in a standard module! So it's back to the drawing board for this mod.

So my first question is: How do I replace fmmt.MouseMove with a
"proper" WindowProc in an OOP-friendly way?

Thanks!

MM



Sat, 07 Jan 2012 22:06:32 GMT  
 Olaf, Jim, et al, I think I've cracked it by defining midiOutShortMsg in a typelib !

Quote:



>> The only "bitte" I would have is that your example is kept as simple
>> as possible, since most of this stuff is totally new to me. Bells and
>> whistles I can add later, once I understand the fundamental concept.

>Ok, done - please download from the same link:
>www.datenhaus.de/Downloads/MidiStreaming.zip
>(now including a SubFolder with the threaded approach).

>> To give you some idea of where I'm at: I took another look at the
>> DirectCOM code: On a scale of 1 - 100 in terms of me comprehending
>> it I would place myself at 3. That is the mountain I have to climb. Think
>> of Everest, then put the Matterhorn on top...

>Nah - if I count the needed changes from the already posted
>approach with the OneShot-MMTimer (already having that
>class-encapsulation of the Stream-engine) - the needed changes
>for the threaded version sum up to only 10-20 lines difference.

>Maybe a good idea, to fully understand at least the structures
>in that simpler Demo first (it is yet contained in the *.zip),
>before trying to find the similarities (and differences) in the
>Threaded approach (contained in a SubFolder of the *.zip).

>What you need to understand from DirectCOM.dll is only one
>needed Declare (to startup the ThreadClass regfree) and one
>ThreadInit-Type which you will have to place the UserData-Pointer
>in, before passing it to the just mentioned StartCOMObject-call.

>The thread is initiated from within the same MainApp-Class
>you already know (cMStream), which now does not contain its
>PlayStream-Routine anymore - this routine is now placed
>(nearly unchanged) in the ThreadClass instead.
>The already known "Message-Receiver-Form" is also yet there,
>in the MainThread - but now not receiving the MMTimer-Messages
>anymore, but Event-Notifications from the thread instead.

>So, the Multimediatimer is gone (not needed anymore) - instead
>we perform an appropriate loop with an interval of 1-2msec in the
>thread-class's ThreadMain-Function itself (triggering your engine
>repeatedly, directly from within that loop now...

>> In the meantime I am, of course, continuing to research threads, C,
>> Appleman, the VB6 Programmer's Guide Creating the Coffee Project
>> (ActiveX)... I never sleep! Well, only about 5 hours a night.
><g>...
>Just ask if something is unclear - but I've tried, to write some
>more comments, how everything "plays together"...

>Olaf

This latest version works pretty much einwandfrei (perfectly!). I am
current running the compiled version, playing a very lengthy piano
piece. At the same time I am loading/unloading/running Opera, Firefox,
Windows Grep, and doing a Find Files. Only very ~slight~ degradation
in the stream if all loads are applied at once, otherwise I can move
the form or scroll the list box, maximise/minimise the form etc etc. I
have not so far found ANY problem.

Now, if we can just crack that WindowProc thingy I mentioned...!

I modified the fMMt.MouseMove code slightly:

   Select Case Status
     Case &H90 To &H9F   ' NoteOn or NoteOff if Data2 = 0
       If Data2 Then
          RaiseEvent NoteOn(Data1, Data2)
       Else
          RaiseEvent NoteOff(Data1)
       End If
     Case &H80 To &H8F  ' NoteOff
       RaiseEvent NoteOff(Data1)
   End Select

to deal with the MIDI alternative way of switching off notes by using
a Note On with a velocity of 0.

I also changed the multiplier in the scrTempo1_Change to 0.1

Also, I don't think all the FTick malarkey is necessary any longer, as
the timing seems to work fine as you have written it. So I shall
probably just leave the core code as it is and forget about FTicks and
so on.

My one doubt is the timeBeginPeriod of 1msec. Is that not too much of
a resource hog compared to 10msec?

Will this all, do you think, also work on XP, Vista and Windows 7? I
shall try it, of course.

Now I'm off to have some late lunch, which today I think will have to
be a Bockwurst in your honour. Yes, we have Aldi in England!

Thanks as always.

MM



Sat, 07 Jan 2012 23:59:51 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Olaf - I've converted your mandelbrot app

2. It's that time Again (et al)

3. I think I've got real problems

4. I've got plenty of nothing (I think)

5. I think I've found a bug

6. Quelqu'un parle fran?ais et peu m'aider avec Treeview et Listview

7. MSDE vs JET 4.0 Multi User et al...

8. Wizard Manager, et al.

9. CAPS and NUM, et al on status bar do not change state when the keyboard changes

10. To Jens, et.al...

11. Time bombs, hari-kiri-ware, et al

12. VBScript and Netscape, et al...

 

 
Powered by phpBB® Forum Software