Programming

I have created a new MIDI format to overcome both the limitations of the current one and the unwillingness of the International MIDI Consortium to develop a MIDI 2.0 file format. So I made my own for my game engine. I even added some primitive scripting features.

But here comes the big problem: now I need to develop an editor. While I created a textual representation of it, which is a weird mix of assembly with Lua influences and essentially musical notes and rhythm as values, but eventually it should have a full GUI editor.

The format so far has the following kind of commands:

• Flow control commands
• MIDI emit commands which can be either:
  • Note on and off commands
  • Velocity change (aftertouch)
  • Program change
  • Control change
  • Pitch bend
  • A few other less important commands (SysEx, etc.)
• Commands for the scripting (Arithmetic commands on writable registers, compare and branch, etc.)
• The ever important wait command, on which the whole system depends, as it tells the sequencer how much clock cycles have to wait between two commands

I have to process these commands for two display widgets, one displays the notes in a piano roll format, one displays any other commands. However, thanks to the way things work, I usually cannot just process MIDI commands directly. For example, notes are defined by a note-on and note-off event (often with aftertouch), no duration. And then comes editing. And then comes to editing around various wait commands. And then comes to editing around various conditional jump commands.

I started to work on a system that converted and separated each command for display, but it's a bit time consuming, and adds extra complexity. But modifying it a bit and adding a "transpiler" to the two systems would make editing pretty easy to implement. I already added "macro"-like features to the textual representation of the format. Could this work?

cross-posted from: https://lemmy.world/post/31184706

C is one of the top languages in terms of speed, memory and energy

https://www.threads.com/@engineerscodex/post/C9_R-uhvGbv?hl=en

OC below by @HaraldvonBlauzahn@feddit.org

What called my attention is that assessments of AI are becoming polarized and somewhat a matter of belief.

Some people firmly believe LLMs are helpful. But programming is a logical task and LLMs can't think - only generate statistically plausible patterns.

The author of the article explains that this creates the same psychological hazards like astrology or tarot cards, psychological traps that have been exploited by psychics for centuries - and even very intelligent people can fall prey to these.

Finally what should cause alarm is that on top that LLMs can't think, but people behave as if they do, there is no objective scientifically sound examination whether AI models can create any working software faster. Given that there are multi-billion dollar investments, and there was more than enough time to carry through controlled experiments, this should raise loud alarm bells.

From their release page:

• Updated to target Android 16 (SDK 36)
• Fixed wallpaper download and apply for wallpapers in assets folder
• Added support for storing the json file in assets folder
• Updated dependencies
• Added support for Global Icon Pack (thanks @RichardLuo0)

edit: The game has been released on itch.io, see here: https://spenguin.itch.io/space-holes (exported for both Linux and Windows)

This is probably my first-ever high-effort game I made with Godot (or any engine, really...)! I've made all the sprites, tilesets, music, sfx, etc. by myself. (The music and sfx were generated using Jummbox and bfxr) And ofc I did all the programming myself too, with only the movement system borrowed from a different game that I never finished (can't waste that nice movement system! I don't want to re-program it again...) as well as the grass tileset (but the decorations on top are new)

I'm very proud of this and I think my pixel art skills have really improved :D

here are some more screenshots:

Vcc - the Vulkan Clang Compiler, is a proof-of-concept C and C++ compiler for Vulkan leveraging Clang as a front-end, and Shady our own research IR and compiler. Unlike other shading languages, Vcc aims to stick closely to standard C/C++ languages and merely adds a few new intrinsics to cover GPU features. Vcc is similar to CUDA or Metal in this regard, and aims to bring the advantages of standard host languages to Vulkan shaders.

Key Features

Vcc supports advanced C/C++ features usually left out of shading languages such as HLSL or GLSL, in particular raising the bar when it comes to pointer support and control-flow:

• Unrestricted pointers
  • Arithmetic is legal, they can be bitcasted to and from integers
• Generic pointers
  • Generic pointers do not have an address space in their type, rather they carry the address space as a tag in the upper bits.
• True function calls
  • Including recursion, a stack is implemented to handle this in the general case
• Function pointers
  • Lets you write code in a functional style on the GPU without limitations
• Arbitrary goto statements - code does not need to be strictly structured !

Many of these capabilities are present in compute APIs, but are not supported in most graphics APIs such as DirectX or Vulkan. We aim to address this gap by proving these features can and should be implemented. More on why we think that’s important.

Introducing Dim – a new framework that brings React-like functional JSX-syntax with JS. Check it out here:

🔗 Project: https://github.com/positive-intentions/dim

🔗 Website: https://dim.positive-intentions.com/

My journey with web components started with Lit, and while I appreciated its native browser support (less tooling!), coming from ReactJS, the class components felt like a step backward. The functional approach in React significantly improved my developer experience and debugging flow.

So, I set out to build a thin, functional wrapper around Lit, and Dim is the result! It's a proof-of-concept right now, with "main" hooks similar to React, plus some custom ones like useStore for encryption-at-rest. (Note: state management for encryption-at-rest is still unstable and currently uses a hardcoded password while I explore passwordless options like WebAuthn/Passkeys).

You can dive deeper into the documentation and see how it works here:

📚 Dim Docs: https://positive-intentions.com/docs/category/dim

This project is still in its early stages and very unstable, so expect breaking changes. I've already received valuable feedback on some functions regarding security, and I'm actively investigating those. I'm genuinely open to all feedback as I continue to develop it!

Repository was archived?

What I think in addition to what Atkinso writes: If you just strip arbitrary bytes that happen to be equal in value to the numeric value of ASCII control characters or whitespace, how can you be sure that you don't destroy valid non-whitespace unicode symbols?

You can't! This will work only of you have actually ASCII input.

Guys, need opinion!

I am an indie dev, a student (still in school), trying to think of ways to earn with just my laptop, internet, and programming skills, any ways as part of my journey I have developed several apps, now as an indie creator with practically no capital, and just reddit and facebook for marketing, should one explore this world of selling apps, your opinion and tips are highly valued so please do comment

P.S I have linked the types of apps I have that I could set up of sale, if you have any feedback on it, do tell https://muhammadj.gumroad.com/l/wifipassfinder

So-called ‘AI’ does not reduce, but rather diffuses and renders labour practically invisible.

With the arrival of Cyber Resilience Act it can be helpful to generate a Software Bill of Materials (SBOM), and to process other to look for known vulnerabilities.

Two open source tools under Apache 2.0 license:

• Syft, for SBOM generation: https://github.com/anchore/syft
• Grype, to process then the SBOM: https://github.com/anchore/grype