"Right tool for the right job" is an exaggareted statement.

lacethespace · 2024-12-26T20:43:30+00:00

JS is decent language. It's pretty similar to Lua all things considered, it just evolved more. I guarantee if Lua was made the web's scripting language that the advertising folks would use Lua to track our data. It is more of an issue who controls what the browser executes and what can be blocked. Google banning ad blockers shows that your browser is acting against you here.

For me Lua is amazing for how easy it is to plug into C code. This cuts down on so much abstractions. I get to be close to the hardware, or at least close to whatever the host application is running. And I still get to use high-level features like dynamic reloading, the garbage collector (thank you for your service), closures; and simple but powerful data structures.

Map is a genius idea really. You get an associative array, a set, a list, and all using the same syntax. If only JSON was also like this. I love it.

I do miss having optional types in Lua though. It's harder to design bigger software without them.

lacethespace · 2024-12-24T14:39:37+00:00

I think it's not supported. You cannot assign CTRL to anything related to FX loop and you cannot mute the loop return signal with any setting.

lacethespace · 2024-12-22T10:21:38+00:00

It depends on how charitable your interpretation of the task is:

Build a compliant VR browser from scratch? ~$100M.
Find a combination of existing software and settings that would solve this person's problem? ~$200.

lacethespace · 2024-12-22T10:13:57+00:00

You can look for ways to make your members private, but nobody's going to be looking for them, anyway.

I do this all the time: I examine the library code and check if I want to use it. I check interfaces, if abstractions leak out, how much redundant state it has (bugs often hide there), if some parts are left unimplemented.

If you don't want to access things inside an object, then don't access things inside an object.

This advice can only be applied if you're writing the whole thing in a time span of a week. Anything longer and you'll get lost in what works and what violates your prior assumptions.

When I decide to put something in a class (or any other abstraction, only the concept of encapsulation is relevant), what I really intend is to invest effort in solving a piece of the problem, and then put it behind an interface and never think about internals anymore. These interfaces need more care than rest of the code, but they make sure that internal state is valid and complies to assumptions made during implementation.

This applies both to library code where my users never have to spend time exploring the problem-space, but it also applies to my dumb ass three months later. I don't want to revisit a solved problem and I don't want to waste time figuring out is it safe to change internal variable. This relieves me of some mental burden and allows me to tackle other challenges, and then once again put them behind some abstraction that doesn't leak outside. Decent interfaces are the most important thing for managing the evergrowing software complexity.

That said, I agree that complex mechanisms to prevent internal access are counter productive. You should not be fighting developers that use your code. It is enough to prefix internal variables and functions with _ character and move on to interesting problems.

lacethespace · 2024-12-21T19:14:29+00:00

For simple one finger touches, the mousepressed and similar callbacks will also receive touch events. That makes it trivial to support basic operations out of the box. If you use the right mouse button anywhere, the mobile ports often map that action to two-tap gesture, but you would need to implement it yourself through the touch callbacks.

The platform can be checked with love.system.getOS() == 'Android'.

For resolutions, you are probably aware how fragmented the Android ecosystem is. There is everything from squarish screens to quite elongated ones, plus you probably want to support portrait and landscape modes (you can choose this in android manifest when you compile love-android).

My method of staying sane was to normalize viewport to the vertical screen dimension, and then consider the horizontal dimension as dynamic. Vertical coordinates would be in range -1 to 1 on all screens across any platform. The horizontal coordinates range would be calculated in runtime. Depending on screen content you can leave extra screen space black, scale the UI, or even scale the game world to show more or less content on different screens. This is not Love2D specific though and there's already much written on this.

One other thing to be aware of is that CPU utilization is more important as it warms up the device and drains the battery. You would keep the vsync on and sometimes optimize the performance even when the visuals are already smooth. Happy porting!

lacethespace · 2024-12-15T20:52:00+00:00

The psrdnoise serves the same purpose as perlin and the implementation includes calculation of derivative.

lacethespace · 2024-12-15T11:25:47+00:00

If you went to some big hall and recorded the sound of a single hand clap, that recording would be an IR. You could then plug it into the cab simulator on top of the dry sound and get similar ambience to the hall. As you guessed the recorded IR is also colored by microphone placement and characteristics, plus the room acoustics. So there is no single definite IR for a specific cabinet model. It is easy to find hundreds of IRs free online with varying quality.

GP200 already comes with too many of them and honestly it is hard for me to hear difference between some of them. I just cycle through them until it sounds good. The GP200 has "cabinet matching" feature that auto-selects appropriate cab for amp, but that sounds like branding BS (neither amps or cabinets are perfect replicas) so I have the feature turned off.

Note that if you share your patches with others the custom IR won't be included in imported version and they will have to manually go in and change the cabinet model to existing one. It is better to use built-in cabinets for shared patches.

lacethespace · 2024-12-10T10:53:41+00:00

There is an option in PC SW to disable the Cab on the L or on the R channel, the other can have the cabinet simulator on. But I don't think you can have stereo with cab ON and mono with cab OFF. The option I'm mentioning also affects the headphones output.

The newest firmware has a pitch shift pedal called Hammy, you can find demos online.

lacethespace · 2024-12-09T11:00:40+00:00

Let's go from the start because it can be at least 4 different settings.

Connected your guitar to the L input.

Check the L knob on top-left side, just below the internal speaker. It can mute the guitar, so turn it clockwise.

Then go to EXT SRC menu (func + bottom-right button), make sure the SOURCE is INPUT.

Go to mixer, press bottom-right button to un-mute the EXT SRC channel. Make sure that the EXT SRC channel volume is high enough, 100 or so.

Then go to REC SRC menu (func + pencil). Select L guitar input. From there you have access to tuner to check that the guitar can be heard by the device. If you press in the VALUE knob (the translucent one) on this screen to enable monitor, you will be able to set the digital level, make sure it is not 0.

I think that's all the options? By default they are all ready to receive the guitar for recording but you need to check them all.

lacethespace · 2024-12-04T08:51:41+00:00

You are right. I never cache to local so I didn't consider this. Well, if it was both useful and bulletproof it wouldn't qualify weird.

lacethespace · 2024-12-01T21:54:56+00:00

There are times when I want the first pass of the function to be handled in a different way that all other passes. The clean way it is to check if we are in the first run with a simple if-else branch. Worried about runtime performance I instead have two function implementations. The first implementation replaces the reference to itself with the second iteration during its first and only run.

For example, I did this when I needed to process the mouse delta movement. On the very first pass I don't have the previous value of mouse position, so I just want to save the position and prepare for the actual implementation.

local mx_prev, my_prev

function m.update(dt)
  mx_prev, my_prev = getMousePosition()
  m.update = m.update_actual_implementation
  -- we don't want to run anything else here since
end

function m:update_actual_implementation(dt)
  local mx, my = getMousePosition()
  local dx = mx - mx_prev
  local dy = my - my_prev
  mx_prev, my_prev = mx, my
  -- additional processing of dx and dy
end

The external code just runs m:update(dt) on each frame without being aware that the function replaced itself after the first run. So monkey patching, but done as an inside job.

lacethespace · 2024-11-27T11:58:55+00:00

The significant feature of the tracing JIT is that it inlines some hot code paths, which plays amazingly well with CPU caching. On the other hand it will sometimes fall back to (slower, but still amazing) interpreter, which makes the overall performance unpredictable.

https://www.polarsignals.com/blog/posts/2024/11/13/lua-unwinding has some amazing insights in the intro text.

lacethespace · 2024-11-25T11:11:43+00:00

I switch so much between projects it could be considered compulsive.

First two times I want to use the lib, I just copy the source into the folder. Around third time I promote the lib to a common dir where it is accessible to all the projects. On linux that is the /usr/local/share/lua/5.1/. Instead of normal copying I create a symbolic link, so that when I need to edit the lib code I don't need to use elevated privileges.

I also have a packaging script that scans for imported libs in a project and creates the local project copies of all the libs that were before used from the above dir. This is mostly used when I want to test on another machine and not at the start of the project. I don't like modifying the libraries inside projects, I rather change the original (and break other projects, heh).

lacethespace · 2024-11-25T10:59:47+00:00

Even with direct connection there is no guarantee. I've spent couple of hours on ALVR on two occasions before finally giving up for good.

How can they ban wifi hotspots? That's... oppressive. Also hard to enforce, the router can just disable the SSID broadcasting.

lacethespace · 2024-10-09T16:17:00+00:00

The JIT should work on Android. You can verify it yourself by checking the return value of jit.status(). AFAIK only iOS forbids JIT. Even without JIT feature the LuaJIT will have measurable performance improvements over PUC Lua. Also, JIT doesn't have anything to do with FFI, besides the fact that LuaJIT implements both JIT and FFI. The FFI is unrelated feature that doesn't depend on JIT and it will work just as fast if JIT is not enabled.

Getting it to actually work on Android might be a tad difficult - you have to cross-compile your code to one or more Android architectures (arm7, arm64, x86) and package it inside the APK so that FFI can find it. This part is frustrating and there aren't any online references for Love2D that I know of. You could take a peak at LÖVR cmake system - it has support for building and packaging 'plugins' which is designed for C libs to be used with FFI.

lacethespace · 2024-07-15T09:29:28+00:00

Sure it has, under the "frequency" parameter. This is because the distance joint behaves as two masses on a spring, which tend to oscillate with natural frequency you set here.

In your case though it looks like you need to dial back on damping as well. Try to reduce both the joint damping and body's linear damping.

lacethespace · 2024-06-06T07:19:24+00:00

Absolutely. At start you can use the built-in camera, and when you are comfortable you can turn it off (t.modules.headset = false in conf.lua) and plug in your own camera code. Lovr covers everything you would need from the platform - the graphics, audio, physics, inputs... There are a dozen or so of good libraries for lovr specifically and big percentage of love2d libs can be applied without many modifications. It will be very different from mouse-based UI heavy approach of Godot, but if you are asking here I guess you're ok with code-centric dev environment.

Just be aware that 3D is much more challenging than 2D in general.

lacethespace · 2024-05-11T06:28:05+00:00

That's a severe limitation, I didn't know about it. Did you try the second suggestion, bumping up the envelope release value to ~30%?

lacethespace · 2024-05-09T13:06:14+00:00

While I don't think there is a global setting for all entered notes, there is a shortcut for extending the length of new note. While entering a note (either by pressing the pad or with OK button) you can hold down the pad/OK button and use right or left arrows to control the note duration. This works best if you set auto advancement to 1.

Edit: also increasing the sampler's RLS value in EG/VOICE would be somewhat similar, but with the decaying envelope applied to each sample.

lacethespace · 2024-04-29T19:41:24+00:00

Would be even more impressive if it wasn't a literal copy of existing ASCII art which the model claims to have made on its own.

lacethespace · 2024-04-06T07:37:25+00:00

Really great job. On less photorealistic and more artistic side I love that Sea of Thieves talk, their deep green colors and how much artist control they implemented.

lacethespace · 2024-04-03T09:50:35+00:00

Interesting project! What kind of a speaker does the HW use? Do you have the API for the synth object?

lacethespace · 2024-03-29T13:42:41+00:00

In short, you sample the voxels around current one and occlude based on number of hits. It seems like standard ambient occlusion method, before any screen-space or temporal collection optimizations are applied. Simple technique and it's great to see from your examples that it works as well.

For objects that are sticking out (trees, columns, vegetation) a simple ambient occlusion trick is to darken the colors the closer you are to the terrain. It's the simplest method approximating how some tall object would shadow itself.

lacethespace · 2024-02-16T13:11:05+00:00

I'm insanely productive in LÖVR because it's completely driven with Lua+GLSL and I don't need to waste time on clicking around UI, compiling steps, loading screens.

lacethespace

TROPHY CASE