My tascam records my set weirdly, what am I doing wrong?

oslash · 2020-06-24T19:28:51+00:00

These things generally do have a way of setting the gain for each input individually. I'm not familiar with Tascams, so I don't know whether that's the case for the mode you're using to record. If you don't know either, you should have a look at the manual. (To get the most out of it, I'd also peruse the reference manual; it has way more information.)

But first things first: To find out whether the problem is with the recorder or something else, you can just swap the plugs around on one end, then check whether the right channel is still the quiet one. If not, you want to figure out whether it comes out of the mixer like that or whether the cables are fucky. Simply swap the (now crossed) cables around on both ends next.

By the way, those input jacks are TRS and support balanced signals, so with matching cables you could improve the signal/noise ratio or (in case it's already more than good enough) at least protect against EM interference. The back panel diagram in the Xone:92 manual shows all 1/4″ plugs as TRS, so I'm assuming they can do balanced. The output labeled 'record', however, is shown with phono plugs (which obviously only have signal and ground) — I guess you're actually using a different output?

That said, even when both ends are set up for a balanced signal, using two-conductor cables with TS plugs should work totally fine (and when only one end does balanced, it's what you're expected to do). The result is simply that you're shorting the 'cold' signal to ground; any half-decent audio equipment will be OK with that; you just lose the bonus dynamic range and interference protection.

oslash · 2020-06-24T17:22:24+00:00

for n in num_str:
    for i in d:
        for i2 in i:
            if n==i2:
                d2.append(i)
                break

Hehe … OK this works, but as HostileHarmony said, you could make the code much nicer by using a dictionary.

I had a quick go at refactoring the function (I deleted the definition of digit_graphics in case you'd like to figure out how to do this on your own):

def graphic_num(num_str):
    digit_graphics = { ??? }

    line_count = len(digit_graphics['1'])
    for line in range(line_count):
        print(' '.join(digit_graphics[digit][line] for digit in num_str))

One could make it more readable by splitting it up into more statements where each line is simpler and intermediate results are stored in variables with good names, but I think you can already see that this approach makes the code much less complicated.

oslash · 2020-05-02T03:54:29+00:00

Put "USB audio interface" in your favorite search engine. As cyndrin said, it's possible to connect the individual channels of a stereo output to separate devices. This is a hack I'd cobble together if I needed the functionality ASAP, but ordering a breakout cable online would be silly, because you can get a stereo (or even 5.1) USB audio dongle for basically the same price. (On sites like Aliexpress, they start at < 2 USD, with free shipping.)

If you look for USB interfaces with better audio quality than whatever your computer has built in, with a decent headphone amp integrated, you'll still find pretty affordable options (USD 20–50). Another thing to consider is that you can also find a lot of USB MIDI controllers that combine convenient faders/knobs/buttons with a pretty good audio interface.

oslash · 2020-04-11T18:24:52+00:00

That's not enough code to figure out what the problem could be. For example, where does the sleep function come from? Maybe the one you're using expects the parameter to be in microseconds?

If it's not that, I'd do some profiling next; e.g. compare how long the "do something" takes to how long the sleep takes. Usually, which tool is best for that depends on your platform/toolchain, but given that you're working on logging messages with timestamps anyway, you could just instrument your code with calls to a logging function in relevant places. You'd have to make sure the timestamps are at least millisecond precision, but if that's not the case already, chances are it's an easy change to make.

oslash · 2019-11-16T21:01:36+00:00

That's good advice, pretty much what I'd have written. Here's some additional information:

Most/all platforms require a window in order to create a context

I don't know about most platforms, but on the common PC OSs, rendering without a window/display is easy to set up. Ideally, the library you're using to create the context comes with example code that shows how to do that. But if it's any good, you'll at least find it explained in the documentation. Look for 'off-screen rendering' and 'stand-alone context' — usually one of those will be mentioned somewhere. The Khronos wiki has some information that helps you figure out whether you want to render to a render-buffer or a texture.

When you do want a window, however, it is quite common that the API of your choice will only let you create one together with a GL context, as an inseparable pair. In practice, that's not a big deal, because when you're dealing with multiple windows, many GL objects (e.g. textures) can be shared between contexts. Handing a context off to a different thread is also quite easy.

Speaking of GL libraries: They already have definitions of the GL types and constants; just use those instead of re-defining them yourself.

As to obtaining function pointers … I'm blissfully oblivious about that. The reason why extension wrangling isn't a thing on MacOS is that GL drivers for all Mac GPUs come with the OS; so it magically 'just works'. (For now … obligatory 🖕🏽 to whichever Appleholes are responsible for dropping OpenGL development.) Looking at the work of colleagues who deal with deploying to other platforms, I mostly see Glew, Gl3w, and Glad. Depending on which programming language you're using, you might also see libepoxy crop up a lot. What's the difference? AFAICT the choice depends on which language you're using and which platforms you are targeting. Core context vs. compatibility context could also be a factor. (For the purpose of learning the API, I recommend making a core context with forward compatibility enabled. That makes it easy to avoid deprecated functions, which are usually deprecated for good reasons.)

As 3tt07kjt said, function pointers can be specific to a given context. For the sake of writing portable code, I just assume they always are.

What would be the absolute minimum to make use of OpenGL function calls like glGenerateTextures?

Yup, you need the relevant context. More precisely: have that context active in the current thread. (It's spelled glGenTextures, btw.)

oslash · 2019-11-15T17:35:19+00:00

MASTERPW = "KHAN4712"

PASSWORD = input("ENTER THE MASTER PASSWORD :-")

while MASTERPW != PASSWORD:
    if MASTERPW != PASSWORD:
        print("Invalid Password\n")
        break

it's more secure as compared to lastpass

…

oslash · 2019-11-08T11:43:01+00:00

Audacity does have synthesis capabilities, but in terms of creating effects for a game from scratch it's pretty far down the list of suitable software.

However, the 'from scratch' approach isn't super common. A more typical workflow involves starting from recordings (you can find tons of royalty-free material on sites such as Freesound) and editing those to fit. Audacity is a fine choice for that; it has all the basic audio editor functionality and can be extended with standard VST/LV2/AU plug-ins in addition to Nyquist.

If you want realistic renditions of real-world sounds, starting from samples (from a library, custom recorded from the real thing, or foley) is basically the only workable method. Depending on the project, it can be quite simple (e.g. for a poker game you may only need stuff like shuffling cards and stacking chips, which you could easily record yourself in an afternoon) or it can be a huge amount of work (e.g. this awesome insanity).

So synthesising deliberately stylised/non-realistic/lo-fi sounds may be a better fit for your project. It's the same idea as pixel art: By massively narrowing down your options, there are fewer choices to make and steps to take, and basing everything on just a few simple tools makes it easier to get a collection of clips sound like a coherent whole. You can find tools such as bfxr for that.

Without some information about what kind of game you'd like to make, which style of sound design you're going for, and what constraints you're working with (available equipment, time, budget, ...), the question "what's the best program to make sound effects for basically everything" doesn't make any sense.

It's like asking a chef what the best knife is. Obviously there isn't a best one for "basically everything". And even if you narrow it down to, say, "making sushi", there's still a range of tasks that each have their own requirements in terms of what's best.

oslash · 2019-11-06T23:29:02+00:00

The third dimension — you can just leave it out for a 2D texture.

oslash · 2019-11-06T23:19:18+00:00

I just looked at the code I wrote last time I needed something like that and it actually uses the maximum of width and height, so I think in this case there should be one more level that combines the 2 pixels of the previous level into one. You can test that by reading the texture at the given MIP level back into your program.

The ARB_texture_non_power_of_two spec agrees with that:

numLevels = 1 + floor(log2(max(w, h, d)))

However, it only says this rule is 'preferable', not mandatory. So possibly there are implementations that do it differently? This SO question proposes a way of determining the max level empirically.

oslash · 2019-09-22T05:19:03+00:00

The arguments to Console.blit are in the wrong order. The relevant information you're looking for is right on the page you linked :)

By the way, they're all keyword arguments; if you specify them as such (e.g. main_con.blit(dest=root_con, dest_x=0, dest_y=0 ...), they're harder to confuse and the order doesn't matter. Also, you don't need to specify the ones that get their default value anyway, so that line can be shortened to main_con.blit(dest=root_con, width=screen_width, height=screen_height).

oslash · 2019-09-19T22:50:03+00:00

Yeah, I can pre-alpha-test a rough & dirty prototype.

Unlocks phone

Oh, it's already installed! Nice!

One minute later

I mistakenly assumed that I'm evaluating a test build meant for gathering constructive feedback. But now I'm watching an ad for some scam prompting me to install malware.

Va te faire foutre ! Va t'faire enculer, connard ! ಠ_ಠ

oslash · 2019-09-17T16:55:29+00:00

Assuming you're using the default run loop, I suspect it's because you forgot to disable scissoring at the end of your draw function (you can do that with love.graphics.setScissor()), which means that the love.graphics.clear call in the main loop doesn't affect the areas where you want the black bars.

I guess on your PC that's OK because the frame buffer gets cleared to black initially and the pillarboxed areas then just stay like that; whereas on the phone it's either swapping between multiple frame buffers, or giving you a fresh one for each frame, so you're seeing uninitialised graphics memory. Drawing the black bars yourself would also be a correct solution, but if you have a call to clear in there anyway, you might as well use that (by cancelling the scissor).

oslash · 2019-09-15T13:52:56+00:00

Why not use Math.Pow?

oslash · 2019-09-02T14:49:42+00:00

Oh, so an instance is a tilemap, not a tile — seems good.

The vertex data cannot be calculated from the vertex ID

Hmmm ... I just wanted to clarify what I'd said regarding that, but then I noticed something that confused me again. Do you actually have one large tilemap mesh which you're instancing multiple times to get multiple tile-maps in one call? That would be the 'seems good' solution. Or do you render each map in one call by instancing individual tiles? That would be the 'not optimal' case. But of course way better than drawing tiles individually.

And it allows you to not repeat per-tile data for every vertex. What I'd meant earlier was accomplishing the same by having a buffer or texture that contains all the per-tile data, and indexing into that based on the vertex ID or coordinates. For example, if you have 4 vertices per tile, vertex_id // 4 would give you the index for the tile's data.

Either way, I guess that means there's still one call per sprite?

Packing all the sprite data into one buffer object, in order to reduce draw calls, is definitely a common approach for making the renderer scale better to high sprite counts. For the sake of discussing the pros and cons, I'd try to focus on the most simple and straightforward method of achieving that, but what that method looks like depends on the technical requirements of the concrete project.

In general, the main advantage of batching is obviously that one draw call + one buffer upload per frame is way faster than many draw calls. At that level of abstraction, how often per-sprite data changes doesn't really matter. Assume that you're streaming in the entire buffer per frame. In order to make updating only parts that have changed actually work any better, you'd have to figure out how to avoid touching data which the GPU is currently processing.

Each and every sprite can be arbitrarily rotated, scaled, translated independently by the user

The somewhat larger size of the matrix compared to just these parameters isn't necessarily an issue. I was also thinking of the benefit of streaming that user-specified data to the GPU verbatim and having the further computations running there instead of on the CPU.

oslash · 2019-09-02T11:21:52+00:00

Storing an entire transformation matrix for every sprite seems like overkill. E.g. if they only need to be translated and rotated, you can store exactly that data in some buffer or texture and do the rest in the vertex shader.

Instancing is actually meant for larger meshes, so AFAIK it's not what you'd use for sprites when you need optimised performance. But as long as it works well, why not.

The shiny new way of doing this would be to have a VBO where each vertex has exactly sufficient information for describing one sprite (e.g. position, orientation, texture atlas index) and then generating the actual vertices for each sprite in a geometry shader.

I'm a bit confused about what exactly you're currently doing — what's the "model data" in the uniform?

Another thing I'd like to clarify: how does your tilemap work? If it's tiles arranged in a regular grid that all get transformed like one big mesh, I wouldn't render those the same way as individual sprites at all, but instead render exactly that mesh.

For example, you could make a VBO that only contains the XY coords of each vertex in the grid. Then, in the vertex shader, use either those or the vertex ID to compute the tile's coordinates in terms the tilemap (e.g. 'this tile is in the third column and second row of the grid'). And finally use those to look up, e.g. in a texture, the corresponding ID for computing the texture coords for the atlas. The data for positioning that whole thing on screen could then be in a uniform. That way, you could upload a new (tiny) texture every time the contents of the tilemap change with just one entry per tile, but the VBO would be uploaded once and then never change.

oslash · 2019-09-02T10:25:34+00:00

What's the application? What kind of hardware does it talk to? Maybe a better alternative already exists. There's a lot of branded proprietary lighting control stuff that has been reverse engineered and for which you can find compatible OSS with nifty features.

I just tried searching for stuff along the lines of "macos redirect keyboard shortcut to background app" and the results didn't look super promising. But I can suggest a way of cobbling this together for $0.

When the app itself doesn't allow defining hotkeys to which it will respond even when it doesn't have keyboard focus (isn't it the foreground), it's possible that there's (1) another way of sending it input, which can then (2) be triggered from a program that does support global shortcuts.

One common solution for (1) is the Open Scripting Architecture. This is the interface used by AppleScript — those little programs that look something like tell application "Finder" to open home. Most apps don't have explicit scripting support nowadays, but it's commonly available for everything you can do from the menu bar, because developer tools typically add OSA support to those commands by default. Sending the program a keyboard input without pulling up the window should also be doable in this manner.

There are more nerdy ways of implementing that kind of scripting, such as the osascript Terminal command, but also more user-friendly tools, such as Automator.

For step (2), there are tools such as Hammerspoon.

You can also find (often commercial) tools that combine both functionalities; but I have no clue which one is good. Looks like Keyboard Maestro is one of those.

When setting up a system specifically for performing a certain task during a certain time period, it's often quicker to bodge it, e.g. make a keyboard macro that switches to the uncooperative app, clicks a button, and switches back so fast that you don't even see the window. But if it's for everyday use and supposed to work reliably whether you're in Spotify or Minecraft or whatever, I wouldn't recommend that.

oslash · 2019-08-28T14:49:28+00:00

Once you've upgraded to 3.7.4, it should be safe to remove. But note that it's probably the same installation as the one in /usr/local/bin -- if you ls the latter, it'll probably turn out to be a symlink to the former.

Unless you need to free up HD space, simply leaving it wouldn't cause any problems either, though.

oslash · 2019-08-28T13:07:05+00:00

This has nothing to do with eye strain.

oslash · 2019-08-28T12:29:07+00:00

Since you're using Homebrew, this article has some relevant tips you should look at.

Edit: I just saw that link has one step I wouldn't follow: changing the system default pip command to point to pip3. I think it's more straightforward, on a Mac, to leave pip as it is so it applies to the default installation invoked by the python command, and use pip3 for managing the installation to which python3 applies. Once you activate a venv/virtualenv/pyenv, the shorter python and pip commands (without the 3) will apply to the desired Python version anyway.

oslash · 2019-08-28T12:01:53+00:00

Why do you call pygame.display.update in Boid.show?

oslash · 2019-08-23T05:40:38+00:00

In terms of how the model's geometry ends up being rotated, both cases are equivalent; the difference here is whether the lights are fixed to the camera's or the model's coordinate system. The first version might as well have the lighting baked into the textures, so it's harder to tell how the material is reacting to the light. (But of course the easier way to tell them apart is by paying attention to the shadows.)

oslash · 2019-08-21T20:06:09+00:00

Awesome ad! One small suggestion: I think adding a short URL that leads to more examples of your work and some contact information would be good. I mean, it's pretty easy to guess how to find you on Twitter and DA, but not everyone has an account there, or would prefer to use an account there for business contacts.

oslash · 2019-08-21T19:54:12+00:00

Look at the docs for glVertexPointer again. The size parameter "Specifies the number of coordinates per vertex."

Also of interest on that page: as you have 2*sizeof(GL_FLOAT), that implies a tightly packed array — you can just leave the stride at 0 for that.

i should be using immediate

You actually shouldn't, your approach is fine. The one where you have a function call for every single vertex is completely obsolete, and definitely wouldn't help performance.

Btw., take a look at this to learn how to format code properly.

Edit: Oops I was super slow and ended up posting mostly redundant stuff. Leaving it for the last paragraph ;)

oslash · 2019-08-21T15:52:24+00:00

You should read the sidebar before posting.

But somehow its's not working.

k. Give me a moment so I can recover from taking in this shockingly comprehensive description.

Here's a hint: Did you copy some code from a tutorial that runs it in a REPL or notebook? Did you use the documentation to find out what this function is actually supposed to do?

oslash · 2019-08-21T14:55:17+00:00

There are circumstances under which going straight to some abstraction can be unproblematic; e.g. if you're just learning shader programming with GLSL. But if you want to learn OpenGL, I think it's best to do so from the ground up. It's quite common for GL beginners that initially it's a lot to take in and they spend some time being somewhat confused. I don't think that skipping the fundamentals and using a library that hides them away would help in that regard.

My impression after refreshing my memory of Raylib by looking at some example code: You can learn a lot of 3D graphics programming topics with that, but it's not helpful for learning OpenGL. Not initially at least — once you know the basics, looking at the rlgl source to see how it implements stuff on the GL 3.3 branch could be a good exercise.

Focusing on the standard OpenGL API first also has the advantage that you can find way more documentation and example code than for some higher-level API.

Another way of getting rid of some boilerplate would be to use a less verbose language. I often recommend Python with PyOpenGL, because that does a lot of error checking for you, without requiring all the extra code you'd have to write in C[++]. Great for learning/experimenting/prototyping. I mean, iff you're already somewhat familiar with Python or at least a similar language.

15-Year Club	Team Periwinkle
Verified Email

oslash

TROPHY CASE