NEXT_TRACK audio tag

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies
BBCode is ON
[img] is OFF
[url] is ON
Smilies are ON
Topic review
   

Expand view Topic review: NEXT_TRACK audio tag

Re: NEXT_TRACK audio tag

by Graf Zahl » Sat Feb 24, 2018 4:05 pm

Major Cooke wrote:
Graf Zahl wrote:I THINK it can be done that upon finishing an unlooped music track some event is triggered.
Uh, unlooped? What specifically do you mean, no LOOP_ tags or? Just a mental note as well, not everyone will be putting in LOOP_END tags -- I certainly cut down on my audio sizes if I can by just cropping them all.

I mean a song that actually ends playing. For looped level music there is no way to detect the loop point from the outside because it's different for each format.

Re: NEXT_TRACK audio tag

by Nash » Sat Feb 24, 2018 2:19 pm

Graf Zahl wrote:So...

I THINK it can be done that upon finishing an unlooped music track some event is triggered.
But here's the catch, and I doubt that Nevander will like it: This would be ZScript-only because everything else would amount to needless complications.
But the event system in ZScript would be perfectly suited to do such a thing in a straightforward manner and leave all the possible options to the modder.
I'd certainly be able to work with an event firing off from the end of an unlooped song.

Re: NEXT_TRACK audio tag

by Major Cooke » Sat Feb 24, 2018 1:18 pm

Graf Zahl wrote:I THINK it can be done that upon finishing an unlooped music track some event is triggered.
Uh, unlooped? What specifically do you mean, no LOOP_ tags or? Just a mental note as well, not everyone will be putting in LOOP_END tags -- I certainly cut down on my audio sizes if I can by just cropping them all.

Re: NEXT_TRACK audio tag

by Graf Zahl » Sat Feb 24, 2018 5:46 am

So...

I THINK it can be done that upon finishing an unlooped music track some event is triggered.
But here's the catch, and I doubt that Nevander will like it: This would be ZScript-only because everything else would amount to needless complications.
But the event system in ZScript would be perfectly suited to do such a thing in a straightforward manner and leave all the possible options to the modder.

Re: NEXT_TRACK audio tag

by Rachael » Sat Feb 24, 2018 1:02 am

Chris wrote:
Nevander wrote:Then what magic method do you suggest for changing the music on demand when both are MIDI lumps and the only logical and possible way to do it is with a timed delay the same length as the MIDI?
If a playlist doesn't work, that may be a viable feature request to automatically start a different song after one ends, without any script timing trickery. Along with being able to specify if the whole playlist loops at the end, just the last song in the playlist loops, or it doesn't loop at all and just stops at the end.
Pretty much this.
Nevander wrote:Getting real tired of your condescending replies that don't help anyone but you and your elitist friends.
I'm going to put my reply in PM since it's very long-winded.

Re: NEXT_TRACK audio tag

by Nash » Fri Feb 23, 2018 11:50 pm

Chris wrote: If a playlist doesn't work, that may be a viable feature request to automatically start a different song after one ends, without any script timing trickery. Along with being able to specify if the whole playlist loops at the end, just the last song in the playlist loops, or it doesn't loop at all and just stops at the end.
I've submitted a mod playlist suggestion a while ago. :D

Re: NEXT_TRACK audio tag

by Chris » Fri Feb 23, 2018 11:11 pm

Nevander wrote:Then what magic method do you suggest for changing the music on demand when both are MIDI lumps and the only logical and possible way to do it is with a timed delay the same length as the MIDI?
If a playlist doesn't work, that may be a viable feature request to automatically start a different song after one ends, without any script timing trickery. Along with being able to specify if the whole playlist loops at the end, just the last song in the playlist loops, or it doesn't loop at all and just stops at the end.

Re: NEXT_TRACK audio tag

by Nevander » Fri Feb 23, 2018 8:53 pm

Rachael wrote:
Nevander wrote:Well the map in question is the titlemap, so it can't be paused with escape or console.
If you must utterly insist on using broken and flawed methods to accomplish timing "tricks" with your music, don't come crying to us when it breaks. And it will.
Then what magic method do you suggest for changing the music on demand when both are MIDI lumps and the only logical and possible way to do it is with a timed delay the same length as the MIDI?

Getting real tired of your condescending replies that don't help anyone but you and your elitist friends.

Re: NEXT_TRACK audio tag

by dpJudas » Fri Feb 23, 2018 3:39 pm

Rachael wrote:If it comes to that, we should probably consider helping dpJudas complete the Hardpoly renderer, since he was working on making it fully API-agnostic - in that the same draw commands could be batched to D3D, OpenGL, or to a Software triangle drawer. That might mean Vulkan support is possible, too - all with a single renderer.
There are differences between the 3D API's (D3D, GL, Vulkan) that affect performance. Those differences aren't particular important in the post processing parts of the code, but they are for the scene drawing. It isn't really possible to abstract those differences away so what I'm trying to do on my master branch is to allow the DFrameBuffer code to boot up with any given 3D backend and then still hand off the actual rendering to a specific renderer.

To be clear here: I'm not trying to replace the GL renderer with hardpoly. The abstraction will just make it easier for renderers to share code that don't really have to differ.

Btw. the main concern I have with what I'm doing on my master branch is Linux. The Direct3D 11 implementation I have in place will make everyone on Windows happy except for XP users, but for Linux there's no "SDL 2D mode" fallback. That means Linux versions of GZDoom will always require OpenGL. I don't know how much of a problem that will be. XP can also still be supported, but that would mean XP users also will have to use OpenGL.

Re: NEXT_TRACK audio tag

by Graf Zahl » Fri Feb 23, 2018 12:32 pm

I somehow doubt that the people this would be meant for, would be able to benefit from it. Don't forget, most of those left-behind systems are not easily upgradeable desktops but bottom-of-the-barrel cheap-ass laptops that are not only stuck with bad graphics support but also with comparatively weak CPUs.

I think that GL2 will bite the dust at the very latest when some multithreading gets added to the renderer. That would necessitate some design changes with moving all the data passing to uniform buffers, but since this old hardware cannot do that it would not even be able to run the multithreaded renderer, unless the old one was kept in as a duplicate. Multithreading will inevitably mean upping the system requirement to GL 3.3 (no, no riskymodernpath anymore!)

Re: NEXT_TRACK audio tag

by Rachael » Fri Feb 23, 2018 12:18 pm

Nevander wrote:Well the map in question is the titlemap, so it can't be paused with escape or console.
If you must utterly insist on using broken and flawed methods to accomplish timing "tricks" with your music, don't come crying to us when it breaks. And it will.
Graf Zahl wrote:
Nevander wrote:People expressed interest in running my mod in that old (1.8.6) of a version...
Ugh...
If those owners of old hardware are even using old versions of the engine, I think we might ditch OpenGL 2 support for good. :twisted: Obviously the target base this is meant for have decided to stay behind not only in hardware but also in software...
If it comes to that, we should probably consider helping dpJudas complete the Hardpoly renderer, since he was working on making it fully API-agnostic - in that the same draw commands could be batched to D3D, OpenGL, or to a Software triangle drawer. That might mean Vulkan support is possible, too - all with a single renderer. We could include a Mesa dll for shader support for those older systems that do not support it, but that would come at a significant cost of performance. (However, Mesa is compiled with LLVM, which means that the CPU shader code will at least be somewhat optimized)

Re: NEXT_TRACK audio tag

by Graf Zahl » Fri Feb 23, 2018 11:47 am

Nevander wrote:People expressed interest in running my mod in that old (1.8.6) of a version...
Ugh...
If those owners of old hardware are even using old versions of the engine, I think we might ditch OpenGL 2 support for good. :twisted: Obviously the target base this is meant for have decided to stay behind not only in hardware but also in software...

Re: NEXT_TRACK audio tag

by Graf Zahl » Fri Feb 23, 2018 11:44 am

Well, then you have a problem - because that age-old timing problem has finally been fixed. And we have absolutely no interest whatsoever to bring it back.
If you absolutely have to have synchronized music, you have to play it as a sound effect - with all the problems that may bring.

BTW, even for the titlemap there are ways to interrupt it without stopping the music - and there's certainly ways to restart the music without the map ever realizing.

Re: NEXT_TRACK audio tag

by Nevander » Fri Feb 23, 2018 11:41 am

Well the map in question is the titlemap, so it can't be paused with escape or console.

My target compatibility for the mod to at least run in, maybe not every little thing working like multi tag sectors (which I don't use because of this) is 1.8.6. People expressed interest in running my mod in that old of a version so that's the one I'd like to target for the low end. I also want it to run flawlessly in the latest since the majority will be using that.

Re: NEXT_TRACK audio tag

by Rachael » Fri Feb 23, 2018 11:27 am

Older versions are completely not a concern for the development team. Graf is right though that you cannot time game sim events to a thread-timed event like the music - one tap of the escape or console key and the timing is already off.

If you're going to support as many versions of the engine as possible, are you going to support ZDoom 1.22 that has literally almost none of the editing elements we have today, except *maybe* Hexen map format, and absolutely no DECORATE support? Have fun with that!

Top