Sound

If there is something important you think is missing in the current version of ZGameEditor then you can post a feature request here!

Moderator: Moderators

chris_b
Posts: 2
Joined: Fri May 23, 2008 4:34 pm
Location: UK
Contact:

Sound

Post by chris_b »

hi, I like to suggest a couple of things relating to sounds:

Variable pulse width for the square wave (even if it's just for Oscillator 1 it would widen the variety of possible sounds quite a lot), with the pulse width available as a destination in the modulation matrix.

Standard ADSR envelopes - where the attack, decay and sustain times are absolute (I think currently the envelope times are relative to the Note Length property).
User avatar
VilleK
Site Admin
Posts: 2274
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

Hi and welcome chris_b. Variable pulse width was planned from the beginning, I can look into that again. And envelope timings also. Maybe a switch that toggles envelope times absolute/relative, that way it won't break backwards compatibility.
User avatar
jph_wacheski
Posts: 1005
Joined: Sat Feb 16, 2008 8:10 pm
Location: Canada
Contact:

Post by jph_wacheski »

oh ,. those are indeed great suggestions,. ADSR envelopes will be sweet! as they are you can get decent effects,. however it is sometimes tough esp. w/ short sounds (<=.1) to get attack AND release, as the sliders don't have the resolution for the fine adjust., if the whole thing where scaled to whatever the lengh of the sound, the fine control would be there. plus 2 moe envilop points is nice too ;) FM will open up lots of new sonic territory,. .
iterationGAMES.com
User avatar
VilleK
Site Admin
Posts: 2274
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

I've had to take a look in the code to refresh my memory.

Current implementation works like this:
- AttackTime = value between 0 and 5 seconds absolute time.
- ReleaseTime = value between 0 and 5 seconds. Release begins when PlayTime>=NoteLength-AttackTime-ReleaseTime. In other words the start is relative to note length, but the duration is absolute.

The time sliders in the GUI only have 100 steps so minimal increment is 5/100=0.05 seconds. I've now increased this to 250 steps making 0.02 steps possible (which currently is the smallest amount of time that will be noticeable because this is the internal update time frame length of the synthesizer).

I'm a novice to audio programming so I thought full ADSR is only usable when you play notes using a keyboard, and not relevant to sound fx in games? Please give an example so I can understand this better :)
User avatar
jph_wacheski
Posts: 1005
Joined: Sat Feb 16, 2008 8:10 pm
Location: Canada
Contact:

ADSR or 3 or 4 stage envilopes.,

Post by jph_wacheski »

I was actually unaware of the exact workings of your 2 stage envilope but it does now make more sence to me,. and giveing the fullresilution to the sliders will likely have helpted a lot too.,

ADSR envilopes give 4 control points to the amplitude shaping of the sound,. and therefor make more complex sounds posible,. esp. with your modulation matrix that lets us use the envilopes for more then just volume,.

here is a good rundown; http://en.wikipedia.org/wiki/ADSR_envelope

even without having an after-touch or key-release measurement the extra wave shaping of one or two more control points will give more sound design abilities and more sounds possible.

I will come back after dinner and make you some example sounds,. with 2, 3, and 4 stage envilopes. you will be able to hear the difference.
iterationGAMES.com
chris_b
Posts: 2
Joined: Fri May 23, 2008 4:34 pm
Location: UK
Contact:

Post by chris_b »

VilleK wrote:I'm a novice to audio programming so I thought full ADSR is only usable when you play notes using a keyboard, and not relevant to sound fx in games? Please give an example so I can understand this better :)
jph_wacheski's link probably tells you everything you need to know...the key point is that the sustain value in an ADSR envelope is an ampltiude rather than a time.

Also the release time can be implemented as either a fixed rate (based on the time it would take to fade from maximum amplitude to zero) or a fixed time (ie. the time it would take to fade from the current ampltiude to zero).

Here's an image illustrates the ampltide envelope for different note lengths (the grey shaded area) with attack, delay and release times of 0.5 seconds and sustain level of 0.5:

http://i32.tinypic.com/ndtnr8.gif

Red has a fixed release rate (time from max amplitude to zero is 0.5s), blue has fixed release time (time from current amplitude to zero is 0.5s). I think having a fixed rate for the release time is probably more logical and straightforward to implement.
User avatar
VilleK
Site Admin
Posts: 2274
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

Hi guys, this is implemented in the new 1.9.0 version. It should be fully backwards compatible. Please help me test this so I can be sure I got it right.
User avatar
jph_wacheski
Posts: 1005
Joined: Sat Feb 16, 2008 8:10 pm
Location: Canada
Contact:

much better now.,

Post by jph_wacheski »

Ok, I have finally had some time to look at the new envilopes. This new system does indeed give much more amplitude shaping possibilities to the sound engine,. very nice!

The biggest issue I find is with the envilope editing,. currently with my mouse wheel I get .1s increments and sliding the slider it is a kina' random editing approach, when looking for tinny amounts, or exact values. As you tell me the increment is .02 perhaps that should be the mouse wheel tick amount,. or perhaps we could have a setting for the editor mouse wheel amount in preferances.
Also I noticed that you can see the value numericly if you hover over the slider,. if it would stay on screen some where,. at least as you move it, that would roc! Another option is to do like BUZZ does with its sliders,. if you right click on a slider a dialog-box pops saying "enter a value (0-whatever is the limit) and a text entry field with a cancel and ok button,. just like your color alpha box!! This way you can leave the current interface AND give exact envilope timing value editing! Well that sounds like the best from my point of view,. but your the one implementing it so do what makes you smile !
Attachments
sounds_newEnv__001.zgeproj
some tests,. just for fun.
(3.16 KiB) Downloaded 719 times
iterationGAMES.com
kattle87
Posts: 402
Joined: Wed Sep 26, 2007 9:06 am
Location: Italy

Post by kattle87 »

maybe we will get some "MIDI instruments" presets? ;) would be nice :D
User avatar
VilleK
Site Admin
Posts: 2274
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

I like the sounds jph! Right-click on a envelope to set value seems to be a quick solution, I will try that.

About midi-presets: I'm not sure which way to go with music support in ZGE. The midi-instrument file is there for anyone to play around with (MidiInstruments.xml, rename to zgeproj to open in zge). The instruments can be defined by hand or by using sampled waveforms from another general midi sound bank. I would need to write code in to support the percussion track but that's not too much work

A whole different approach is to remove midi-files altogether and instead write a importer for XM/MOD-formats. XM files are compact and file specifications are available so it would seem to suit ZGE. Or are there other formats that would be even better?
User avatar
jph_wacheski
Posts: 1005
Joined: Sat Feb 16, 2008 8:10 pm
Location: Canada
Contact:

jph's thoughts on ZGE sound..,

Post by jph_wacheski »

Well first off, I am a big huge fan of realtime sound generation,. that was one of the very first things that drew me into ZGE,. one of many! Being able to link sound generation peramaters to game action is a super great feature. I have utilised it somewhat,. but I do think the best is yet to come.

The problem of music, for me at least, comes from the lack of pattern editing., Editing midi outside of the sounds that it will actually play seems somehow strange to me,. however when I realised that the current midi implementation has the ability to trigger in-game events I was quite excited by that, and still am. (My REZ inspired music game can be created!) I just haven't gotten around to creating some midi tunes to play/test with,. For me the ultimate soultion would be that the ZGE editor have a small/simple midi sequence editor added to it,. just a little tracker-ish spreadsheat type thing,. that way the music creation would be fully conected to the sound playing engine, and music could be composed in realtime. Of course, that would require a huge effort,. so I should just find a super simple freewear midi editor and do that composing work like that.., may happen this week end!

As for the "MIDI instruments" presets I can start on that,. if I do a couple a day we could have them all in a few weeks,. however it is unlikely that they will sound much like the names, or 'work' with every midi file,. tweeking will always be needed for specific songs. It will be a start for those ppl that don't want to learn to edit synth presets, so I will try it.

XM/MOD support would be a nice feature,. but not at the loss of the current synth-engine/midi,. IMHO. Mods are great as there are millions availble and they are CAN be small and are self contained,. again the more ability to read note values and control the playback of the mod the better,. i.e loop pattern 3,. change tempo to 128 bpm, mute chanel 2, etc. stuff that will make trully INTERACTIVE music for games and demos. Perhaps wait for this untill a way is found to do what Kjell was suggestion and have the exe only include what is needed. or mod playback could be the frst optional include..,

For a 'better' music/sound format the best thing I know of is the 'V2 synthesizer system' [ http://www.1337haxorz.de/products.html#v2 ]I belive you based ZGEs sounds on some of that source,. i guess including it as a music player is out of the question due to it being a c++ system? I lov it for the truly great sounds it is capable of along with the insainly cleaver system that saves the songs as systhesis/sequence data! 2-5k for a full multitrack song with realtime effects and synthesis changes!! love that. The good thing is that the engine in ZGE now coupled with the current Midi should allow nice small music to be produced as well,. so I would leave changes to that on the back burner again IMHO.

Is it also just not currently posible to have ZGE link to dlls ? as that would open up so many 'add-on' type things,. physics 9 pass values out get vectors back), mod players, etc,. however I think i recall delphi not wanting to talk to dlls,. ?
iterationGAMES.com
kattle87
Posts: 402
Joined: Wed Sep 26, 2007 9:06 am
Location: Italy

Post by kattle87 »

the point is: Ville would like to follow the "KISS!" (Keep It Simple, Stupid!) principle: single file, single game. Adding external dlls means take care of lots of things, mainly related to variable types. Linking to dlls is sometimes great, sometimes painfully. The real point is: are we wanting dlls or not? Little dlls could be VERY handy (with some tricks one could get strings and other things working) but we might be missing the key feature of ZGE: simplicity.

Personally, I would like the possibility of calling external C code for some reasons (mainly 2d arrays for a project I've abandoned based on breakout :wink:) but this is gonna be hard convincing people that we *DO* need dlls...

BTW: For what regarding the "One file, one game" feature, one could easily import dlls as a resource inside the exe, then unpack it as hidden file as soon as the program starts, then use it, and at the end just delete. I had already found Delphi examples for doing it :)
User avatar
VilleK
Site Admin
Posts: 2274
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

The funny thing is that a early version of ZGE (before first release) actually had a pattern editor for music. Although it was very primitive and quite difficult to use. I figured that no one wants to compose music this way so I threw it out when I started the midi-import function instead.

Of course a xm-import function could still trigger the OnPlayNote and similar event which would allow for procedural runtime changes of the music.

The V2 is great, and yes I've based some of the ZGE-synth on documentation from the author of V2.

Delphi can work with DLLs so there are no technical hurdles for that. But it collides with some of the design philosophies I've kept with ZGE so far.

As kattle says, I'd like to have simple and have single file distributions. A dll could be embedded and extracted runtime (GM does this) but it just feels clumsy to me. The dll would be embedded as data which mean it would not be recognized as x86 code by the packers, which leads to poor compression. Physics/music dlls etc are sometimes >1mb which ruins the 64kb philosophy. Finally it violates the cross-platform design.

The idea of linking to a custom dll for game logic that cannot be done in current ZGE is good though, but I'd prefer the solution of building a custom component (TBreakoutLogic) in Delphi instead of a separate dll (breakoutlogic.dll). Of course that means learning pascal and maintaining a separate version of ZGE for your game, but it really is not very hard.

Some more ideas:

1. A future version of ZGE with redesigned scripting language could import dll's directly using the scripting language.
2. Separate branches and binary distributions of the ZGE-code base for "ZGE cross platform" and "ZGE Win32 with V2 and physics dll's".
kattle87
Posts: 402
Joined: Wed Sep 26, 2007 9:06 am
Location: Italy

Post by kattle87 »

we are going off-topic, but what I really need is a rewritten scripting language :D nothing more than it ;)
Have you any idea on how to add lots of stuff in a simple way? I mean, will it need complete rewrite or not? (EG: arrays, functions, possibility of using "for" statements inside a ZExpression and so on...)
User avatar
jph_wacheski
Posts: 1005
Joined: Sat Feb 16, 2008 8:10 pm
Location: Canada
Contact:

Post by jph_wacheski »

yes that is my biggest problem making games with ZGE right now,. the limited scriptability,.(and of course my lack of basic math knowlage,. but that is my falt ;)) However,. the more it try, I find there are often times ways to do what I want to,. in roundabout ways. But still, I really would like to be able to pull values from specific instances of a Model type,. preferably using instance_nearest(x,y,n,type), instance_furthest() style addressing,. and for sure passing values between objects when they collied! bouncing is sorta a btch to implement currenly,. for example. plus the data storage and string stuff is a bit of a loss,. as well as saving data to files,.

but all that said,. I am still having great fun working WITHIN the limits, as I too very much enjoy the 64k size and the cross-platform greatness! The reason I brought up dlls was in thinking that if the door was open, and someone really needed x,y or z function (mod player, physics, force-feedback on a 360 controler, etc., etc.) they could likely locate or create a dll to do it,. since ZGE is open source anyhow perhaps it is a small point,. as usual just dreaming out loud..,

yeah we are way off topic here,. but interesting to hear everyones thoughts.
iterationGAMES.com
Post Reply