um I thought accessible_output2 was mac compatible?
This OS error I posted earlier seems to come from accessible_output2, voiceover.py, reference, or whatever
has anyone ran into the same problem?
um I thought accessible_output2 was mac compatible?
The error is as follows:
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/aeosa/appscript/reference.py", line 460, in __call__
return self.AS_appdata.target().event(self._code, params, atts, codecs=self.AS_appdata).send(timeout, sendflags)
File "/usr/local/lib/python3.7/site-packages/aeosa/aem/aemsend.py", line 92, in send
raise EventError(errornum, errormsg, eventresult)
aem.aemsend.EventError: Command failed: OS error (-1743)
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "speak_through_sr.py", line 7, in <module>
auto.speak("This is a test.")
File "/Users/uri/git/agk3/examples/AGK/speech/auto.py", line 5, in speak
File "/usr/local/lib/python3.7/site-packages/accessible_output2/outputs/auto.py", line 25, in speak
File "/usr/local/lib/python3.7/site-packages/accessible_output2/outputs/voiceover.py", line 15, in speak
File "/usr/local/lib/python3.7/site-packages/aeosa/appscript/reference.py", line 496, in __call__
raise CommandError(self, (args, kargs), e, self.AS_appdata) from e
appscript.reference.CommandError: Command failed:
MESSAGE: OS error
COMMAND: app('/System/Library/CoreServices/VoiceOver.app').output('This is a test.')
Two topics, but the same question... .
Accessible output 2 itself states that it is, but as it works with developing stuff, you don't update your implementation for some time, but development on Apple's side continues, so Apple might have built something in or changed some event parameters or whatever and accessible output 2 simply didn't adapt to those changes, since it isn't in development anymore. I guess thats just the case here.
Looking forward to getting new version of TGTR released in Python for both mac and Windows. I love how people crap on a language without knowing anything about it. Then they wonder why no one wants to help them.
#30 (edited by ogomez92 2018-12-04 17:42:41)
Oh come on, let's not get started on this. you've been BGT all the way until someone whoever made you see the light. that's even worse I think. Stop trying to make people look bad, you'll most likely get the same treatment.
Just because at one point I said that I thought python is slow (never meant to crap on it like you say since I use python for NVDA addon coding, the little I have done that is. So you are the one who should stop trying to start shit because when I kindly asked you the other day whether you could share some information about Python audiogame development you went on about how you are using some private tools and being a bit of a proud ass about it.
C# can be decompiled easily, although the comments, variable names etc will be removed from the code.
but, consider python, which the packagers like pyInstaller will append that into an executable.
so, how would you decompile the code without knowing the offset in the file where the (zip) file was appended?
this requires you to reverse-engineer the executable file + you have cython as well which helps you to convert your python's code in c. so, you will compile that into a c module and call it from python without any hassle like memory management stuff.
python is as fast as it should, since it doesn't compile to native-code (which is cpu-based, which is os dependent), but python's bytecode by itself can run on any operating system or cpu which python can be run on. so, it should interpret that, then execute it.
this also happens with c# as well. with the difference that python is an interpretor, while .net runtime has a just in time compiler.
It says OS error, and that checkbox is checked on my end, not sure what's wrong. will try again later
30. Yes. You are correct. I am using private tools. The world is not open source. You'll survive.
#35 (edited by Liam 2018-12-04 19:29:07)
Also I'd actually like to take the time to respond to 30 other than my one line response.
Oh come on, let's not get started on this. you've been BGT all the way until someone whoever made you see the light. that's even worse I think.
I have been shopping around for alternatives for at least a year, but until Python I could not find anything that met my needs.
Stop trying to make people look bad, you'll most likely get the same treatment.
I feel like they do that to themselves just fine.
Just because at one point I said that I thought python is slow (never meant to crap on it like you say since I use python for NVDA addon coding, the little I have done that is.
Does the argument in my streaming group not count? You were very adamant that Python was useless for game development. Even in this forum topic you have reiterated this fact.
So you are the one who should stop trying to start shit because when I kindly asked you the other day whether you could share some information about Python audiogame development you went on about how you are using some private tools and being a bit of a proud ass about it.
So I'd like to address this for a second more thoroughly. Oriol came to me and asked me if I could give him advice. I kindly explained that I was working with some code that was not publicly available and couldn't discuss all of it. Where I could I attempted to answer questions about which libraries to use and so on. Oriol chose to get snappy with me when I refused to divulge how I was doing such things are encryption and packing as those are things that are not public. If those who I am working with decide to make that public, then that's a different story, but esentially I'm being asked to betray the trust others have put in me for someone else's gain. It has nothing to do with being a quote unquote proud ass, it has everything to do with agreements and decency.
There is also sound_lib which is built on pybass which uses bass. Huzzah for layers. It works extremely well and is cross-platform unlike libaudioverse. Python's only failing is the lack of up to date libs, but Bass is still actively being developed and runs fine.
#37 (edited by Ethin 2018-12-04 19:48:03)
@35, I know what you mean, and feel you. Python may not be C# but its still a very good language, and audio game development definitely is possible with it. So, yes, I agree with Liam on this point: if you don't know the language, besides NVDA add-ons (which really is no indicator you actually know the language, and have developed things within it that are actually useful -- such as audio games or REST API clients), you have no right to crap on it and claim that its useless for something -- especially since you haven't tried! You've tried some old audio toolkits, OK. But have you ever, you know, asked someone like me, for example, to either attempt to update those modules that are out of date for you, or, perhaps, to develop a custom audio module for FMOD?
And yeah, for audio games, Python is lacking in some areas. But Python wasn't exactly designed from the ground up for gaming. I mean, even C++ has out of date audio libs that are still used; OpenAL is one such library and its practically used in almost everything, despite its age and how people crap on it for its OpenGL-ish like way of doing things and how its very difficult to work with.
oh nooo. Avoid FMOD like the plague. Unless you have thousands of bucks laying around for licensing or unless you plan on never ever selling anything in your life.
#39 (edited by Ethin 2018-12-04 20:01:46)
Oh, FMOD is nice. Very nice. For open-source projects its perfect. And I think their licensing terms are a bit different.... yep. Here are the terms: If you earn under $500000.00 per project (I think), you get it for free. After that, you gotta pay. Since I doubt an audio game company will *ever* earn over $500,000.00.... well....
We understand the drive to create, innovate, explore. For you creators, we think you should use FMOD free of charge – all the features, no limitations.
If your game development budget is under $500k or you’re not doing it for the money, go ahead and start creating. Simply register for a free license and include our logo in your game, before it is released to the world.
Then in their FAQ they say that earning money in any form is not allowed for the indy license. It's why I just waved hello and goodbye to it. No doubting that it's a sweet engine though.
#41 (edited by Ethin 2018-12-04 20:13:03)
@40, wow... what double standards. Rofl But yes, it is a suite engine. The only true alternative though is BASS and OpenAL. And BASS is proprietary as well -- I think, anyway.
Bass has a decent pricing structure. I think it's @200 eros for 2 platforms, but that allows you to release all the projects you want so long as the price is under 50 euros or so. And I think it's a one-time payment, though I could be wrong on that. I'd have to check.
bass doesn't support hrtf as far as i think.
but i'm sure about its support on fmod and openAL
I think it does, or there might be a plugin for it. Its good enough at least that I was considering using it in one of my projects before I abandoned it in favor of other things. Perhaps I'll reboot that project if I can find a good way of distributing plugins, or find a good plugin architecture.
Let me just clarify a few things here, before everything gets out of place.
1. I said Python was useless because of the following reasons: 1, I tried a couple of projects which use it and were slow. One had a very noticeable keyboard latency and the other took a very long time to run and the game was just not snappy, unlike other audiogames.
That said, maybe I chose the wrong words. sometimes we do get emotional about things, and I appologize for that.
Second, I am not asking anyone to develop outdated libs for me, that is outrageous. I am merely trying to find decent alternatives or ways to do things, hence the reason I'm asking. When I asked Liam for advice, it was not so that he would sed me his private tools or whatever, I merely wanted to get an idea from someone who was already working on a game project about how to do certain things like audio, keyboard, and so on, And this is the reason I got snappy, as Liam pointed out. Because instead of offering general advice, his comment was that he was using private tools and could not disclose information. I never asked you to send me any of your tools, and I wouldn't have unless you said they were open source.
I hope this clears things up a bit, and I appologize for my over emotional response.
That being said, I do not wish to dramatize things, nor have issues with Liam who seems to be an OK person despite this recent hickup. while it is true that I could have handled things differently, it was out of hand for Liam to post about me crapping on a language and etc etc. Let's just forgive, agree to disagree, and move on?
Bass doesn't support HRTF but this could probably be done with a VST plugin which in theory bass supports.
BASS doesn't support HRTF by itself, but you could implement this functionality easy enough in several ways. One would be the VST plugin route mentioned earlier, then again BASS supports DSP functions, so why not add HRTF processing in those. I myself am going to develope a BASS add-on providing HRTF functionality until August 2019 as a proof of concept, showing that major implementations are possible and maybe even starting a major add-on for that purpose. You could even wrap up some other, already existing lib like SteamAudio and simply forward the DSP processing from BASS to this library, achieving the same goal.
@45 maybe the game was slow because you coded it... not in an optimal way? don't know, just wondering.
have a nice day.
I'm fairly sure 45 is referring to undead assault which ran okay fo rme, but others had a ton of issues. I'd say we've come pretty far though in optimizing code for audio games, at least. I'd like to think so.
At Liam and auriel, i just want to advise you guys to keep the heat to a minimum, i see that things are calm now, but the tone was getting a little aggressive from where i stand.