Just gave the NetStream example a whirl, and it is able to play a stream for about 74ms but after that it just loops on the last couple of samples?
The stream I tried was
I tried it on Winamp at it worked fine.
This stream was from shoutcast.com, I opened one of the streams listed in the .pls file. I’ve also tried other streams with the same effect.
This was using any of the Build configurations.
Tracing it, you no longer get debug messages in the debugger, so I am assuming that it is freezing in Fmod.
[quote="Sly":2r9zmbt0]I haven’t had a chance to do much with the pre-alpha over the past couple of days because we are near gold candidate deadlines for our current game. Should be able to do some more over the next few days hopefully.[/quote:2r9zmbt0]
hmmm… still haven’t had much of a chance to play with it. Making gold master candidate builds has been killing us. Plus I’m trying to finish off wedding plans. Yeah, I’m getting married this Saturday. Hey Brett, we’re coming down your way for the honeymoon. Hiring a car and driving around Vic.
[quote="brett":3tgh76cm]Im a bit hesitant to say how much cpu the new software engine will take on a pocketPC though 😆 [/quote:3tgh76cm]
Ahh, the PocketPC is just a glorified calculator anyway. ducks and hides 😀
[quote:3tgh76cm]I’m sure if you come through melbourne i’ll be happy to meet up and say hello.[/quote:3tgh76cm]
We’re in Melbourne for a couple of days. I’ll give you a yell later in the week via email. It will good to meet up.
[quote:3tgh76cm]Note that the api has changed slightly as well, so the VB / delphi headers will need to change again. I think it is mainly in the enums and defines, and maybe a few function names have changed.[/quote:3tgh76cm]
Gotta keep us on our toes. I will check back after Sep 9 and make any updates to the Delphi headers then if the new release is out.
With the Get functions that take a pointer to a buffer and a pointer to a size, how do we determine the size? Is it the two call method like many Microsoft functions, ie. pass NULL for buffer in the first call and the function populates the size parameter with the required size, then we allocate a buffer of that size and call the function again? Or do we pass in a buffer of a predetermined size?
[quote="brett":2s1c3oq3]Now 1024 is full, and also 0 based so it actually means there are 1025 volume levels, but it also means exactly 1024 is unity, and now there is an even ‘half’ volume of 512, whereas in fmod3, 127.5 would have been half which you couldnt set, so you had to almos randomly choose between 127 or 128. [/quote:2s1c3oq3]
Very nice, looks like I get what I have asked for a long time ago:
[quote="Sly":2s1c3oq3]Yeah, I’m getting married this Saturday.[/quote:2s1c3oq3]
Congratulations, have a great wedding and a nice honeymoon.
I have finished the VB6 declarations for fmod.h and fmod_dsp.h
You can download the vb6 module here: http://www.djdecks.be/fmod/FMod4VB6.zip
I quickly tried creating, initializing, loading and playing a sound, and it seems to be working just fine.
The only problem I had is that when running my program from within Visual Basic that I get a ‘Bad DLL Calling Convention’ error from Visual Basic on the fmod calls.
When I first compile to an .exe and start it everything works as it should.
There are some other things that I need to try also because I don’t know how well they will be working in VB.
One problem is that there is no unsigned type in visual basic.
I’ve used a regular signed 32-bit integer for now, but haven’t tested it yet.
I suppose that this should give no problems up to 2147483648 but for larger numbers it would go negative…
I think I may also try to create some VB Objects that wrap the calls so that you can use it in the same way as the c++ objects.
These objects could also hide some of the pointer stuff with vb.
Just wondering what is the difference between fmodex.dll and fmodexp.dll ??
Also, Brett could you give a brief explanation of how the plugins work? Does FMOD dynamically load all found in a plugins sub-directory or how does it work?
I restarted the Delphi port. I tried to do a diff between the headers you supplied earlier and the headers in the distribution and there were too many differences in arrangement of blocks, spacing and comments to pick out relevant changes.
I’ve done fmodtypes (includes fmodcodec and fmoddsp because having them separate would have resulted in circular unit references), fmoderrors, fmodpresets and half of fmod.
I’ve got the distribution and my port in a local Subversion repository now so I can more easily track changes to both the Delphi files and the official FMOD files.
i think the version you previously used was fmod.h.html right? it was generated by a code->html parser, and fmod has been changed a bit since that conversion, so yeah its probably a bit different.[/quote:na78fz5q]
Yeah, that was what I based my first conversion on.
[quote:na78fz5q]i look forward to seeing your work, i’ll stick it in our source control.
I wonder if the delphi stuff could be autogenerated. We actually generate fmod.h from fmod.hpp :)[/quote:na78fz5q]
There is a C-to-Delphi header converter tool available, but it makes a mess of fmod.h. I have also thought of writing my own converter tool, but there are enough special cases where it wouldn’t work. For example, a couple of enums in fmod.h have been converted to constants in fmodtypes.pas because they can be combined with other values using the OR operator. In Delphi, this would require converting the enum to an ordinal then applying the OR operator.
How do you generate the .h from the .hpp? Do you have your own tool to do that?
I’ve been using FmodEx since it was released for testing, and am happy to report great success so far.
I’m impressed by the awesome response times when you pause a stream, and continue playing. This used to take a couple of ms, and was noticeable as not stopping the instant you told it to, Nice work!
I am well aware that you are still working on this, and of how laborious this task is :roll:. I noticed some differences with the SetVolume calls. It used to be 0-255, but now it seems to be more like 0-3000 ? (I’m assuming maybe 4096, but i can’t notice much difference after 3000, so maybe 2048?)
It appears that you are using the Sound class as a resource, and then using the System object to play a Sound resouce. Might I suggest that for better OOP practice that you have a ‘SoundSample’ and ‘SoundSource’. In this way you would create a SoundSource, that could have 1 or multiple SoundSamples, and then an attached System to play it on. In this way you would then have your SoundSource object, and to play it, you would call SoundSource.Play(), instead of passing the Sound to the System.
I’ve been itching to start playing with the new callback system, due to being able to get a callback at the 2 stages. Have you guys made any progress with this as yet? (Last attempt returned ‘not implemented’)
I saw mention of this feature, will this automatically be supported by FMOD, or is it just a simple case of loading the next song in when the callback for EOF is executed?
I hope my feedback is useful in improving an already stunning library. Keep up the awesome work!
Good to see the unimplemented errorcode is working
What callback is it that you specifically want? What do you mean 2 stages?
I can implement certain callbacks if you want them for the next release.
Was actually wanting the EOF callback. Both when the file streamer has finished with it (stage 1) and when the sound engine has finished with it (stage 2) (as described in the help)
Wanted to use this to do my own stitching, as FModEx hasn’t got support just yet.
I havent got around to that, i’m wanting to support stitching with arbitrary files instead of just FSB this time, but it will take a bit more thought. (switching formats on a stream requires codec creation/destruction/mallocs/frees in the middle of a stream playback which i don’t like too much but it might have to be done, it just creates multithreading issues)
I think this will be awesome for you to get working. Perhaps through a callback to allow a user to tell it the next file to load? Or perhaps it should be an optional switch when you create the System object?
Of course, it depends how much time you want to spend on it, because the ability for me to be able to seamlessly stitch at the end of a song, but to also crossfade when changing songs would be welcome.
I don’t mind doing the crossfading myself, but if you are doing stitching and using threads, it might just be a small step to also add the volume increasing/decreasing and simultaneous playing of both streams. Of course you would know best, so please let me know what your thoughts are on this,
The first pass at the Delphi headers are available here
(Note: this is my home PC so it may not be accessible at all times)
I have yet to fill out fmodclasses.pas, but the rest of it is there. I’ve tested it to play a basic sound and exit and that seems to work fine.
Please login first to submit.