Magma: C3 Roks Edition v3.3.2 [07/28/15]
- This topic has 697 replies, 6 voices, and was last updated 1 year, 8 months ago by fungusDig.
-
AuthorPosts
-
July 4, 2013 at 10:17 pm #402703
Are you sure? Ever since I switched to using Magma C3 I’ve had this problem. Every custom no matter how many instruments have had the left audio coming out both speakers.
July 4, 2013 at 10:20 pm #402705considering over 200 people have downloaded (and presumably used) this version, and all the current authors and songs being authored are being done with Magma: C3, i’m fairly certain i’m right.
July 7, 2013 at 7:13 am #402767UPDATE!
Hilariously enough, I lost the source for v1.1.3 so I only had 1.1.2 on my computer…so I had to re-do 1.1.3…while I was at it, added a few suggestions that had been made and made a few fixes…ALSO, we can now specify the audio encoding quality – many kudos to raynebc and NewCreature for making this possible!
As with all other tools and options i’ve provided you with, use it with caution. It is not known if there is a problem with having too much big audio file customs at once. My test song compiled at 13.8MB at regular (3) quality, 14.2MB at the new default (5) quality, and at 38MB at highest (10) quality.
Also, this version makes it ridiculously easy to avoid “version” conflicts with songs as they get updated, as requested by our own Nyxyxylyth.
I tested it quite a bit but it’s also 3am, so you let me know if I derped something in the build.
same link in the OP…along with fresh pictures!
v1.1.4
- enabled option to change audio encoding quality and raised default from 3 to 5
- added option to automatically increment song version based on succesful build - can append this to the file and/or to the song ID. You can change it manually or let Magma add +1 everytime you build successfully.
- re-enabled ability to type into the audio stems, rba file and album art directories (had been disabled previously)
- various small miscellaneous improvements to the code
July 7, 2013 at 12:49 pm #402772Maybe I missed it but is there any info on the rebuilding when audio is not changed? Magma C3 recompiles every time while the original Magma didn’t, I don’t remember if this was already addressed.
July 7, 2013 at 1:41 pm #402773I’m fairly certain i’ve already answered this. I did not make any changes that would affect that behavior, since that is controlled by MagmaCompiler. What you may see as “Magma doesn’t use the audio from the old RBA” is because you most likely have checked off “Delete Old RBA First”…which, well, deletes the old RBA, so MagmaCompiler can’t access it!
I just tried it, took about 1 minute to compile from scratch, 1-2 seconds to compile with the old RBA file present.
now that we’ve introduced version numbers it’ll be an issue since the new rba doesn’t match the old rba due to the newer version name. so if this is so important, I can append the version number to the CON file only, not the RBA, and that way you still get the benefit of quick compiling when the audio hasn’t been touched.
let me know, easy fix. i personally prefer to spend the extra minute and know my RBA is totally fresh than to use an old RBA.
July 7, 2013 at 1:54 pm #402774What you may see as “Magma doesn’t use the audio from the old RBA” is because you most likely have checked off “Delete Old RBA First”…which, well, deletes the old RBA, so MagmaCompiler can’t access it!Yes, it actually was selected. What’s the function of that feature? I mean, would you suggest using it when?
let me know, easy fix. i personally prefer to spend the extra minute and know my RBA is totally fresh than to use an old RBA.
Well, I would prefer the tested and untouched one, any new build might introduce an issue that wasn’t there before. But anyway, it was the default preference set, so it’s all good. ” src=”/wp-content/uploads/invision_emoticons/default_SA_smile.gif”>
July 7, 2013 at 2:02 pm #402775Yes, it actually was selected. What’s the function of that feature? I mean, would you suggest using it when?
it is enabled by default because I strongly believe starting with a new RBA is better, since you know exactly what’s going on with your latest build. so I would leave it enabled by default for my purposes. I can the default be disabled easily.
Well, I would prefer the tested and untouched one, any new build might introduce an issue that wasn’t there before. But anyway, it was the default preference set, so it’s all good. ” src=”/wp-content/uploads/invision_emoticons/default_SA_smile.gif” />
disabling it right now I suppose doesn’t do anything, as the new RBA doesn’t match the old so there is no benefit to leaving the old RBA beyond having different versions…should we go back to overwriting RBA files (so you have this time saving option)?
July 7, 2013 at 2:16 pm #402776it is enabled by default because I strongly believe starting with a new RBA is better, since you know exactly what’s going on with your latest build.
If it’s only about forcing tne audio to be compiled from scratch, it’s the other way around. Once the audio is compiled and you have tested it in game and you’ve found no issues, you know exactly how the audio is. On the other hand, if you force a rebuild every time, you don’t know what you’re dealing with, because the encoder has done its work from scratch and anything, from the audio file being corrupted for any reason or the encoder having messed up because of low memory or whatever, may have changed. It’s very probable that nothing bad happened, but if we’re only talking about the audio and if your concern is knowing what you’re dealing with, using the latest tested audio is as close as you can get to what you want. Besides, any change to the audio will force a new build, so you don’t run the risk of not compiling a new version of the audio track.
disabling it right now I suppose doesn’t do anything, as the new RBA doesn’t match the old so there is no benefit to leaving the old RBA beyond having different versions…should we go back to overwriting RBA files (so you have this time saving option)?
I’m afraid I don’t get how it works then. I thought the option right now deletes the old RBA first, so not deleting it will cause Magma to pick up audio from the old RBA, would it not?
July 7, 2013 at 2:24 pm #402777I’m afraid I don’t get how it works then. I thought the option right now deletes the old RBA first, so not deleting it will cause Magma to pick up audio from the old RBA, would it not?
that was how it worked when the song was always being compiled as “song.rba”…so “song.rba” was there. now you compile “songv4.rba” and the next time it’s “songv5.rba”, so it doesn’t see it as already being there.
i’ll change the behavior so the v# only goes to the con/live file so the RBA is always the same and gets picked up as already being there by the compiler.
as far as using the old vs new rba…I’ve ALWAYS manually deleted the RBA files before every compilation. I don’t know for certain that the only thing that isn’t redone is the audio when the old rba is there…for all I know it may not be changing other things as well. that’s why I go from scratch.
July 7, 2013 at 2:32 pm #402779that was how it worked when the song was always being compiled as “song.rba”…so “song.rba” was there. now you compile “songv4.rba” and the next time it’s “songv5.rba”, so it doesn’t see it as already being there.
Ok, yes, then I took that as a given: if you change filename, the audio is built from scratch.
July 7, 2013 at 3:50 pm #402781One more thing: when you disable an audio track, you lose reference to the original audio track. Which means that if you need to check issue compiling a single instrument or disabling temporarily any instrument, you then need to go back and readd the audio track.
July 7, 2013 at 3:55 pm #402782You guys are killing me. that was also done purposefully…I guess not everyone likes things being neat. I really disliked having the disabled text box with text in it and the error icon because you don’t have that audio file…I know somebody who reuses the magma project files and those are there every time! ” src=”/wp-content/uploads/invision_emoticons/default_SA_wink.gif” />
I can also put that back…
July 7, 2013 at 4:06 pm #402783You guys are killing me. that was also done purposefully…I guess not everyone likes things being neat. I really disliked having the disabled text box with text in it and the error icon because you don’t have that audio file…I know somebody who reuses the magma project files and those are there every time! ” src=”/wp-content/uploads/invision_emoticons/default_SA_wink.gif”>I can also put that back…
+1
Also similar: if you disable an instrument, it clears the difficulty.
July 7, 2013 at 4:23 pm #402784so it’s becoming evident all the features that I thought made it better are actually not? or is it because you guys are too set in the old ways and don’t want a new way to do things?
make me a list of what you’d like me to restore because it’s starting to accumulate it seems.
July 7, 2013 at 4:33 pm #402785so it’s becoming evident all the features that I thought made it better are actually not? or is it because you guys are too set in the old ways and don’t want a new way to do things?make me a list of what you’d like me to restore because it’s starting to accumulate it seems.
Two things I strongly advise against based on my experience in selling apps to customers:
1) Taking feedback personally: you’re using a large chunk of your free time to do this, nobody would ever dream of disrespecting that. However, people will ask you for things to make their experience better, that’s not a reason to feel bad about it.
2) Removing features that work simply because you’re accustomed to doing things in a certain way. And that’s even more true for an application that has been around for some time. Because you’re accustomed to doing things in a certain way makes it harder to realise what happens to the app usability once you remove some features.
-
AuthorPosts
- You must be logged in to reply to this topic.