Blitz Basic - MED problems

[Hungry Horace]

Originally Posted by pmc

Where do you set volume? Have you tried doing something like this:

call player
set your volume
call player
set your volume

So that (hopefully) your volume settings continually override what the player code just set. Bear in mind that I know nothing about BB2 and how you handle interrupt calls with it (which is I presume how the player code is called) so I might be talking total rubbish!

sadly, not an option. the med.player sets it up in the interupt itself, so, once triggered, the tune is always playing until told to stop. It's obviously this 'setup' that is resetting the volume control i think.

Alternatively I wonder if there's any mileage in picking apart the med player and trying to work out where / how volume is set and then altering the code to suit your needs?

almost certainly there is, in regards to using the 'standalone' player mentioned in my first post. However, doing this is a little beyond my knowledge at the moment (thus why i'm asking all the questions) but i'm always willing to learn.

As another suggestion, do you have to use med? You might have more options by using ProTracker for example as you'd have more choice of player code...

this is exactly what i am doing in the meantime. There's certainly no 'rush' for me to use MED format at all. Unfortunately though, i've had to 'butcher' a lot of my tunes, a slow and ugly process. I often use things like >64 lines in a pattern, and the pitchbends operate differently between MED and PT, so i'm still not entirely happy with the conversion.

Although i can now get-by without using MED, setting a decent set of commands up for it would be one job done that i could use again-and-again in the future.

[Leffmann]

Replay routines will set the volume registers regularly, and writing them never really worked with any replayer. I'll try poking that volume setting in the MED file later and see if perhaps that works.

[Hungry Horace]

Originally Posted by Leffmann

Replay routines will set the volume registers regularly, and writing them never really worked with any replayer.

Not sure i understand this - how does it work on the MedPlayer and PTplayer commands i currently have set up in Blitz then? I am pretty sure they are not the h/w volume controls.

[Leffmann]

Replay routines should scale any value they use to set the hardware volume by a master volume. At least this is how Protracker and compatible replay routines do, and they work as expected.

Since there are effects and commands that alter the track volume (hardware volume), changing the hardware volume yourself will typically result in a flickering volume level. What do the BB MED volume commands sound like?

[pmc]

Originally Posted by Leffman

Replay routines will set the volume registers regularly, and writing them never really worked with any replayer.

Looking at the ProRunner2.0 replayer code I can see that this routine does just this and often writes the volume registers for the four audio channels.

However, it does this from a set master value that it manipulates as part of the routines it has for fading music in / out at start / end of playback as required.

I wonder if there's a similar "master volume" variable in the med replayer code?

If you manipulate this variable from your code rather than the volume regs directly then the replayer should use this altered volume for it's own subsequent writes to the volume regs.

That should solve the problem of the player overwriting the volumes you set in the hardware registers directly.

[Leffmann]

No master volume in the MED replayer, but it was just two lines of code to fix that.

I'll see if I can write it all up together a multi song selector later. Though I'm not keen on diving into the BB command extension mess, unless there's a really good guide somewhere?

[Hungry Horace]

Originally Posted by Leffmann

No master volume in the MED replayer, but it was just two lines of code to fix that.

I'll see if I can write it all up together a multi song selector later. Though I'm not keen on diving into the BB command extension mess, unless there's a really good guide somewhere?

the lha posted above apparently has everything set up with 'easy to use macros' for the job, and examples.

thanks for having a look

What do the BB MED volume commands sound like?

perfectly normal

[clenched]

Here are my observations so far:

1. on the sample program Examples:amigamode/medplayer.bb, if the SetInt is changed from 5 to 3 there is a definite change in playback speed.Not to suggest it will fix problem but only other IRQ is available.
2. Downloaded a few other med to test and discovered if the first four bytes were "MMD3" a guru always ensued. The lambada.med begins with "MMD0" and plays ok.

Would it be possible to post the actual med giving trouble or, if it's under wraps, something else that similarly misbehaves?

[Hungry Horace]

Originally Posted by clenched

Here are my observations so far:

1. on the sample program Examples:amigamode/medplayer.bb, if the SetInt is changed from 5 to 3 there is a definite change in playback speed.Not to suggest it will fix problem but only other IRQ is available.

2. Downloaded a few other med to test and discovered if the first four bytes were "MMD3" a guru always ensued. The lambada.med begins with "MMD0" and plays ok.

Would it be possible to post the actual med giving trouble or, if it's under wraps, something else that similarly misbehaves?

Hi clenched. These observations are sadly something i have tried all of.

Indeed changing the interupt used does change the timing, but it's no timing for a musician. You'll notice lambada.med using the 'default' SPD (not BPM) values used in Octamed.
I use in my tunes, often small loops that are heavily dependent on exact BPMs. These can still not be achieved correctly and with any degree of accuracy with a change of interupt to 3. The command is well-documented to be Vblank based, and this is why it operates fine using SPD timing in interupt 5

Both MMD0 and MMD1 formats work fine. MMD2 also crashes (suggesting med.library is not being used) whilst MMD3 does not even exist afaik! (certainly not in Soundstudio 1.03c)

There are several MEDs i have giving the problem, and sorry, no i'm not willing to post them as they are going into projects i am currently working on. I am sure there must be plenty on aminet though which use BPM timing?

[Samurai_Crow]

Originally Posted by Hungry Horace

Both MMD0 and MMD1 formats work fine. MMD2 also crashes (suggesting med.library is not being used) whilst MMD3 does not even exist afaik! (certainly not in Soundstudio 1.03c)

There are several MEDs i have giving the problem, and sorry, no i'm not willing to post them as they are going into projects i am currently working on. I am sure there must be plenty on aminet though which use BPM timing?

An MMD3 is just an MMD2 in Mix mode. You need octamixplayer.library to play an MMD3 and just hope you've got a good enough processor to do it. No '020s allowed here folks.

I'd suggest using the medplayer.library for any 4-voice hardware-banging playback but keep in mind that the BPM is only accurate in Mix mode anyway I think (due to being called by a hook routine when the mix buffer needs to be recalculated for the next frame).

[Hungry Horace]

Originally Posted by Samurai_Crow

An MMD3 is just an MMD2 in Mix mode.

Ok. It doesnt say that when you save the file!

Originally Posted by Samurai_Crow

I'd suggest using the medplayer.library for any 4-voice hardware-banging playback but keep in mind that the BPM is only accurate in Mix mode anyway I think

sorry, but i've used Octamed Soundstudio since it was new, and that simply isnt true. The -only- player getting the BPM wrong here is the Blitz one. It's exactly the same with Protracker mods that also allow for accurate BPM which is CIA timed, and that is what i am currently using.


As you might guess, i never use mix-mode!

[Leffmann]

Does anyone know how to make Blitz 2 load user libraries? I've been following the instructions by the Blitz 2 author but I can't get it to see my self made library.

At startup Blitz will look for the deflibs file in its root directory and load it if present. This file is a digest of libraries. If this file is not present it is supposed to look for the blitzlibs: directory and load all libraries present there and in the sub directories, but this never seems to work.

If I use the makedeflibs tool to create a new deflibs file out of all libraries I get a file which is larger than the original, but seemingly lacking some of the more basic commands, and of course my own commands.

Anyone?

[BippyM]

Basically the libs need to be incorporated in the deflibs file. There are 2 lib files. Acidlibs which are all the acid libraries.. and deflibs.. Each library has a unique ID upto 255 which it needs assigning. The libs are then combined and can be used.

[Leffmann]

Yes this is what the makedeflibs tool does - it loads all individual libraries in the blitzlibs: directory and sub directories and digests them into this deflibs file, but for some reason it does not include my own library properly. Still, the author himself does write that if the deflibs file is not present it will load the individual libraries instead from the blitzlibs: directory. Does this work for anyone?

One thing it does do is act on the command names, and do erroneous highlighting on them. F.ex if I type my command "OMEDInit" it will replace it with "EndInit" and highlight the End keyword.

[BippyM]

try using deflibman.. It is what I used to use.. There is another prgram that does the same but is far more versatile.. Cannot remember its name though :/

[Hungry Horace]

i use http://aminet.net/package/dev/basic/BlitzLibMan 'Blitz Lib Man' to manager my libraries.

It lets you scan BlitzLibs: and switch on/off your libraries as required, from which you can then rebuild the deflibs file. I used it to get the ProTracker libraries working and it's proven itself to work rather well.

[Leffmann]

Alright this took some time. I've had to rewrite small bits of the replay routine to make the extension work after I finally figured out that an extension must only contain a single hunk (a BB extension is a plain AmigaOS executable) or it will fail to load/screw other extensions up.

The BB2 author's guide to extensions is brief and doesn't mention how to do complete error checking and reporting back to BB2, so the error checks are few. All MEDs I've tried so far have played fine though. Let me know if there are any errors and we'll see if we can fix them.

OMEDOn OMEDOff - Turn OMED on and off.
OMEDLoadFromFile "filename" - Load MED from disk.
OMEDUnload - Unload current MED.
OMEDPlay [song] - Play the first song, or any song from 1 to N.
OMEDStop - Stop playing.
OMEDContinue - Continue playing.
OMEDVolume volume - Set volume from 0 to 64.

[pmc]

Legendary work Leffman.

[Hungry Horace]

Leffman, that is excellent. Thank you very much. I hope you will be putting this on Aminet when it is done? (And hopefully including your source for anyone who wished to learn from it?)


I have a few things i'd like to ask about;

- the original MED commands in BB2 allowed you to start the tune at a different Song position. Do you think this would be possible to add as a second (optional) parameter for OMEDPlay?

E.g. OMEDPLAY 1,5 - play song 1 of loaded song from position 5.?

The other thing i would ask about is that the old command (and similarly, the PT commands i'm using) allow you to load several tunes at once into 'banks' . Is there any mention of how to do this in the docs, and/or would it be difficult to add? (i guess this would mean a 3rd parameter in OMEDPLAY!)

Anyway, current version is very good and will help me a lot i'm sure.

[Hungry Horace]

ok. post number two.

I have implemented this into my test program, which currently plays 3 different meds. Due to the limit i mentioned above with the non-usage of banks, these are each loaded upon selection, and then played (rather than my previous "preload" method)

However, the chip memory consumption between loading and closing the program, even with the current module being "unloaded" and OMedOff being called at the end of my program, is alarming. Ok, so my MEDs are quite big. a few hundred Kilobytes each. but even running a memory clearing program when back into workbench did not help.

additional:

i have found that if i now use OMedUnload before i load a new module, there is no such problem with the chipmem. I cant help but think this "problem" would be easier/more obvious to work-around with the multi-loading system in place - although it is currently helped by the fact the Unload does not complain if there is not a MED loaded.

Anyway, i dont want to create too much for you to look into Leffman, but i think what you've created here is something really useful.