This topic contains 3 replies, has 2 voices, and was last updated by  osc65 1 month, 3 weeks ago.

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
  • #106114

    Hi everyone. I just wanted to make a thread for the script repo so that people can ask questions here in the forum. It should be known by now that I’m not a FP og FB friend so … here we go. ( I just had to Terry … sorry *grin* )

    I guess this info applies to everyone that authors tables, and of course the guys that have applied 7.1 to their cabs.

    One of the first things you notice is that some tables starts to sound crappy. That is because by default, sound in VP imported into VP is placed on the table instead of the background/backglass. Before you put those exciters in and changed the sound setup, you probably ran 2.1 and had all sound sent to the backglass no matter where they are placed in the table. Most of the users that make 7.1 setups use exciters. The sound gets slightly muffled so you don’t really want sounds that doesn’t belong on the playfield/table to be set at such. This is especially important for Originals and EMs. There are corner cases though. 3 Angels pr. example. You might want to leave some of the thunder and rumbling in the table for the effects and feedback. If you don’t understand what I mean. Please head over to VPF and get the latest (1.1.1) and the previous version (1.1.0) of Serious Sam and compare where the sounds are placed in the Sound Manager. In general you can kind of say. Put every sample to the backglass. Only leave the sounds like flippers, bumpers, solenoids, diverters, plungers … etc – that are actually regular object on the table.

    This will not make a problem for 2.1 users. It just makes it good for everyone !

    I decided a while ago to update some of the older tables that was made pre 10.4 where Surround Sound was introduced to VP with better positional placed playsound calls. In short, with 10.4, a 9th parameter was added to “playsound” and the community has come up with some sub routines that makes them easy to use. Actually. It is easier now, if authors just adopted to the new routines to place sounds more precise than using the long comma separated stuff they’ve always done before. In 95% of the cases you just need to use ‘playsoundatball “sample”‘ – that sub is using ActiveBall to tell where the hit is made. Don’t use it for spinners though. It just doesn’t make sense that the spinner sound follows the ball ;)

    So, I decided. Let’s make this available for everyone, so look no further than this url

    I still see tables made today that totally ignores SSF. And that just makes me sad, becase it means the author have put unnessesary work into putting the samples in the hard way, and also incompatible with SSF. Reuse of template code ?? Please updated your templates guys.

    So, this script repo – is it the perfect solution and will all the tables sound perfect once I replace the script ?

    NO ! There are a few typical routines where a re-write just wasn’t feasable just because of the shear number of tables. Typical example is drop target banks. The code looks something like this.

    Set dtLDrop = New cvpmDropTarget
    dtLDrop.InitDrop Array(sw1,sw11,sw21),Array(1,11,21)
    dtLDrop.InitSnd SoundFX("DropTarget",DOFTargets), Soundfx("DropTargetreset",DOFContactors)

    Set dtRDrop = New cvpmDropTarget
    dtRDrop.InitDrop Array(sw0,sw10,sw20,sw30,sw40),Array(0,10,20,30,40)
    dtRDrop.InitSnd SoundFX("DropTarget",DOFTargets),Soundfx("DropTargetreset",DOFContactors)

    This is taken for the Amazing Spiderman. And what it does is basically saying play sample “DropTarget” for sw1, sw11, sw21, sw0, sw10, sw20, sw30 and sw40 – and reset with the sound “DropTargetreset”. I don’t have a good solution to re-write this efficiently so that it plays the drop sound at the correct location. So, these are left in there and since they are by the author – not positioned you probably are going to hear them as placed approx 1/3 up the table.

    The ideal case would be that the authors updated their tables, using sound manager to put where DropTargets and Reset where to be played. But, you see the problem here … the same sample names are used so that will not work. I don’t expect all tables to be updated. I just hope that authors is more aware – maybe they too some day sees the light and tries SSF enabled setup :)

    For the users of the script repo. If the tables don’t get updated. I recommend that you try for a few of them to place the sounds like I described just now yourself by using the sound manager. And of course in this case you have to change the script too so you can distinguish between the placements of the drop target banks. (change one of those subs with new names and import new samples with different names, you can export the originals and import or make it maybe even more exciting, get slightly different sounding ones) Of course, if this only appear once, just using the sound manager is enough.

    And, if you find errors in the tables that is up there. Please share the fixes and we are going to see to that they get updated. Currently it is me, DjRobX, Wob  and Arngrim that has write access, but, that is simply because these are the guys that have asked for it.


    Just as a question, with objects like bumpers, flippers etc. is there only a simple on/off trigger here – or can multiple events (i.e. sound files or values) be assigned to a single object?

    I know that VST plug-ins can be inserted at the end of the output chain….but wondered if it was feasible to have – say 8 values – assigned to table bumpers, and at least 3 or 4 to flippers?

    My thinking on this is along the lines of MIDI velocity values….where the ball glances off a bumper or hits it square-on and hard, or soft, or somewhere in-between….
    On a real table, this sounds different.
    If multiple values could be assigned to each of these playfield objects you could do one of a couple of things:
    – trigger a different sound file
    – use the value to dynamically change a filter/EQ curve/compressor response

    I think the latter approach would be better – less work for table authors/less files to manage – and VST plug-in settings could be easily stored and recalled – either by the table itself when loaded, or by the user. Obviously, the plug-in would need to have the ability to respond dynamically….the VST API supports MIDI velocity values (0-127 or offset 1-128). As above, between 4 -8 assignable values would be more than enough…so 25, 50, 75, 125 or whatever….if MIDI velocity values were used as the control trigger events).

    From a programming perspective, I don’t know if this is feasible….and whether or not these bumper etc. “velocity” values could:
    a) be assigned to a playfield object/translated to MIDI events
    b) be passed through to the VST plug-ins at the end of the audio signal chain.
    Further to this is the question of whether or not the DSP could be inserted earlier in the path – either using a built-in DSP engine or incorporating a VST insert point where it would be most effective?



    Great questions. But, I believe we would have to change the way sound is done in VP in order to make this possible. If you look at some table script, you soon will notice that all we can do is to play samples and place them somewhere on the playfield. It used ot be just left and right, now we have the Y-axis as well. VST is something that comes “after”. Some scripts do have different samples depending on many things like speed or height of the ball, just not implemented as well on each.

    So, to your first question. There is actually many tables that have more than one sample for one event. Just look at those sound mods. They play a sound and a tune. There are other tables where if the ball has over X speed it plays one sample instead of another. Others again, higher pitch etc.

    Would love to see further improvements being done on sound in vp, so, thank you for at least asking questions. Without them, less chance that it will be looked at.

    • This reply was modified 1 month, 3 weeks ago by  Thalamus.

    Thanks for the response Thalamus….

    I knew it would involve a pretty significant change….and obviously would be dependent on available development resources – but struck me as a potential option that could provide enormous flexibility….without fully reinventing the wheel – given that the VST and MIDI API/protocols are well-established and resources are readily available.

    Hopefully, the idea has some legs – and one of the folks on the VPX/PinMame development team can consider it.


Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.


WP2Social Auto Publish Powered By :

Log in with your credentials


Forgot your details?

Create Account