Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion GroupsVB SyntaxEnterprise DevelopmentDatabase AccessControlsCOMWin APICrystal ReportDeploymentGeneralGeneral 2
Related Topics
VB.NET / ASP.NETMS SQL ServerMS AccessOther Database ProductsMore Topics ...

VB Forum / General / July 2009



Tip: Looking for answers? Try searching our database.

It's finally here! midistreamingv104.zip with full VB6 source code

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
MM - 28 Jul 2009 11:07 GMT
http://www.littletyke.myzen.co.uk/ktn/midistreamingv104.zip

This includes all the source code, runtime Dlls and Exe. A Readme.Txt
file is also included. The ZIP file is 106KB in size.

MM
Norm Cook - 28 Jul 2009 12:59 GMT
Tried numerous .mid files, none would open=>error generated
with the ConvertMIDIType1to0 call.  (Knowthenotes project)

> http://www.littletyke.myzen.co.uk/ktn/midistreamingv104.zip
>
> This includes all the source code, runtime Dlls and Exe. A Readme.Txt
> file is also included. The ZIP file is 106KB in size.
>
> MM
MM - 28 Jul 2009 13:51 GMT
>Tried numerous .mid files, none would open=>error generated
>with the ConvertMIDIType1to0 call.  (Knowthenotes project)

Maybe your application folder is protected in some way? I have run the
exe on 98SE, XP, Vista and Windows 7 with not a single problem after
playing dozens of MIDI files, type 1 and type 0.

If your system disallows the creation of the temporary file, that
might explain it.

MM
Norm Cook - 28 Jul 2009 14:12 GMT
App Folder protected:  No, using XP SP3
No problem creating Tmp files.
The files I tried are the three files shipped by XP
in C:\Windows\Media: flourish.mid, onestop.mid, town.mid
I also tried some Mid files in the Program Files\Creative
folder, which were supplied by my sound card install.

>>Tried numerous .mid files, none would open=>error generated
>>with the ConvertMIDIType1to0 call.  (Knowthenotes project)
[quoted text clipped - 7 lines]
>
> MM
MM - 28 Jul 2009 14:25 GMT
>App Folder protected:  No, using XP SP3
>No problem creating Tmp files.
>The files I tried are the three files shipped by XP
>in C:\Windows\Media: flourish.mid, onestop.mid, town.mid

I don't have them to hand, but I do have C:\WINDOWS\MEDIA\PASSPORT.MID
and C:\WINDOWS\MEDIA\CANYON.MID, both of which are type 0 files and
they loaded and played immediately.

My guess is the search path. The system can't find vbhlp32.dll for the
shift routines required by the conversion routines.

MM
Schmidt - 30 Jul 2009 01:30 GMT
> >App Folder protected:  No, using XP SP3
> >No problem creating Tmp files.
> >The files I tried are the three files shipped by XP
> >in C:\Windows\Media: flourish.mid, onestop.mid, town.mid

> My guess is the search path. The system can't find vbhlp32.dll
>  for the shift routines required by the conversion routines.
I'd suspect that too - should be testable with running the
compiled Exe - if that works, then the VB-IDE does not
"see" your vbhlp32.dll.

Maybe replace the few shifting-functions with selfwritten ones,
to get rid of that dependency - or just do a preload in the
same way as with the DirectCOM.dll, so that it works within
the IDE.

Olaf
MM - 30 Jul 2009 09:14 GMT
>> >App Folder protected:  No, using XP SP3
>> >No problem creating Tmp files.
[quoted text clipped - 6 lines]
>compiled Exe - if that works, then the VB-IDE does not
>"see" your vbhlp32.dll.

However, I later, test-wise, removed VBHlp32.dll from \windows\system
and the app still found it in the application folder.

>Maybe replace the few shifting-functions with selfwritten ones,

I suppose my reluctance to do high-speed routines in B.A.S.I.C.
instead of assembler can be traced back to when I started on slow 8088
PCs and VB1/2/3. For years I used Crescent Software's QuickPak Pro for
these kinds of routines. However, PCs *have* got a lot faster, so
maybe nowadays there is minimal difference in execution speed between
ASM and Basic. But there is one other consideration that always
bothers me and that is that VB integers are signed. Doesn't this cause
a problem when doing "shifting" the Basic way through multiplication?
To avoid all these issues I just always thought, nah, it's not worth
the hassle, let's just whack an ASM routine in there!

However, I take your point and will do some speed tests, and test the
effects of "signed-ness" using extreme values that are unlikely to
crop up in practice.

>to get rid of that dependency - or just do a preload in the
>same way as with the DirectCOM.dll, so that it works within
>the IDE.

Doing the preload is the most interesting point you raise here,
because this is something I have never contemplated before.

By the way, since you're here, I have noticed some ~slight~
degradation in the screen performance only on Vista and Windows 7.

I summarise this as follows:

1. Windows 98 SE: App continues to play when the form is moved or the
grid (or listbox) is scrolled. The virtual keyboard, however, stops
(see below for comment)..

2. XP: App continues to play when the form is moved or the grid (or
listbox) is scrolled. The virtual keyboard ALSO continues! (This is
the best performing platform of all four O/S's.)

3. Vista and Windows 7:  App continues to play and the virtual
keyboard also continues, but there is ~some~ degradation when the form
is moved. The visual effect is that one sees traces of the form
shadowing the form as it is dragged around the desktop while the music
output slows down a little momentarily. The slight degradation is only
momentary, in that the music slows down slightly for a second or two,
then stabilises again. The slower I drag the form, the less noticeable
is the degradation. The shadow/trace effect happens when I drag *any*
window around the desktop (see comment below).

NB: I'm not worried about the virtual keyboard stopping on 98SE. The
fact that the music continues to play is the most important.

On Vista/Windows 7 I could put the degradation down to lack of any
decent graphics card in the test PC. Namely, there is none! Only the
onboard (mobo) graphics are used. And both Vista and Windows 7 strike
me as being particularly heavy on the use of graphics resources. I did
try experimenting with Compatibilty options, but no combination I
tried appeared to make much difference. Nevertheless, as far as I'm
concerned the app with its revised playback engine is a success on all
O/S's, and from Larry we know that it works on W2K as well!

MM
Larry Serflaten - 28 Jul 2009 14:11 GMT
> Tried numerous .mid files, none would open=>error generated
> with the ConvertMIDIType1to0 call.  (Knowthenotes project)

It ran fine on Win2000. I happen to have a stash of midi files.
Aside from the Type 1 to 0 (or whatever) red message, they
all (all the ones I tried) played fine, and what's really neat,
I could move the form while the music played!  <g>

LFS
MM - 28 Jul 2009 14:19 GMT
>I could move the form while the music played!  <g>

That is the fundamental new aspect of the new playback engine!

Thanks for the feedback.

MM
MM - 28 Jul 2009 14:18 GMT
>Tried numerous .mid files, none would open=>error generated
>with the ConvertMIDIType1to0 call.  (Knowthenotes project)

Another idea: Maybe you need to place vbhlp32.dll in
\windows\system(32). You can't register it, 'cos it's not COM, but the
search path may not include your application folder. NB: The full
version has a manifest file, but I found one was not needed for the
Minimal Demo.

Maybe you can try with a known type 0 file (doesn't need conversion).
Here's one:

http://www.littletyke.myzen.co.uk/ktn/sample.mid

MM
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2010 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.