To authors and SSF users

[Thalamus]

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 https://github.com/sverrewl/vpxtable_scripts

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. (UPDATE : New core will fix this – late April 2020)

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.

You need to login in order to like this post: click here

[osc65]

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?

 

You need to login in order to like this post: click here

[Thalamus]

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.

You need to login in order to like this post: click here

[osc65]

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.

 

You need to login in order to like this post: click here

[jadflat]

Hi, some great work here, thank you!

I’ve got a 2.0 SSF set up currently and will soon upgrade to 7.1.  Am i understanding correctly that the scripts just need to be renamed as my table name and placed into the tables folder?

You need to login in order to like this post: click here

[Thalamus]

That is correct. Just go to this url : https://github.com/sverrewl/vpxtable_scripts – press the ‘Clone or Download’ – green button. (or use git client – mentioned below ( recommended )) Unzip the download to eg. c:\temp or something. Now, take the script and put it in the same folder as the table. NEVER EVER rename the script that you download. If you need to do that to match the table they are most probably not made for the table in question. And by matching the table, I mean, exact table name = Firepower_2.1.vpx => Firepower_2.1.vbs

Unfortunately, there are some authors that don’t use version numbers at all in their uploads. That is when you kind of have to test the script or compare it to the original. I can’t force authors to use version numbers and I have no good solution to this. You could always try the script, but, be very aware.

I actually recommend using git client to download with. Why ? Because there is still changes being made. Arngrim sometimes fixes DOF and I might change a thing or two. By using git client you don’t need to download all files each time and you will very easily see new files that is added or changed. Or, of course, you can also make note of date when you download and then check the changes history. See if changes has been made via the web interface since last you downloaded. More work and obviously why I recommend using a git client.

If you at one time is happy with the script, you can just open the table with the script in place. Press save and then delete the script. You have kind of “updated the table” at that point. Each time VPX sees a *.vbs file in the same folder as the table, it will replace the script on loading. So, it is safe to test these as long as you don’t press save. Hope this makes sense.

 

You need to login in order to like this post: click here

[Thalamus]

I wanted to update this post with – for me very exciting news. I’ve talked to Michael about the playsound that exists in core and he has over the weekend come up with Saucer, Kicker and DropTarget that just played a sound without any directional position to something that really works. I’m still running tests, but, to me it seems to be working very well. When this new updated core is going to be released ? I don’t know. Soon is my best guess, and of course, it might still have bugs. He actually has two versions right now. One being more precises than the other in that Toxie compiled into VP table dimensions. That is for the upcoming next 10.7 beta I guess. But, if you can live with hardcoded tables of dimension of 1000×2000 which to me sounded precise enough, then there is a version for that too.

You need to login in order to like this post: click here

[flstclasic]

This will be great! Thanks for the update.

You need to login in order to like this post: click here

[Author]

Posts