A #Polyend #Tracker song has 8 tracks and 48 instruments at most. A pattern can have 128 steps.

Let's consider MIDI export.

Since an instrument can change per step (instrument is one of the note parameters), in the worst case scenario you would need 48 * 8 = 384 MIDI tracks to export a single 8 track pattern. This sort of gives perspective on the complexity of this instrument.

#Ableton and #Bitwig have a sort of solution for this: drum rack. So if you had a plugin that can play polyend instrument then you would need 8 instances of drum rack each with in worst case 48 instances of that plugin and choke group spanning all of the instances. I.e. in worst case you would be running 8 drum racks and 384 instances of the plugin. Pitch could be changed with generated pitch automation. More feasible than 384 MIDI tracks but still somewhat exhausting.

Did not realize how complex problem it can be to do 1:1 correct export of a tracker project until I started to actually think of it :-) As odd as it sounds it would easier to implement software clone of the tracker than to implement a DAW export of a tracker project.

@bugaevc @josh or alternatively to this scheme shm known by all processes could be used as a database to keep track of things. For me this looks like sort of problem that is pretty nasty to solve without any shared repository to get bird eye view of the process tree.

@josh @bugaevc Maybe it is not a fit for the case but one more heavy-lifting way would be to have a daemon/service that you would connect with UDS socket and processes would report the situation and that service could perhaps send fd that could be used to query/report. This is about what I was thinking but probably too far fetched I guess.

I.e. you have a piped process tree and outside service to keep track of things...

@josh @bugaevc I meant just that when you receive fd's you can check by sender's sgid's whether it is legit sender and make assumptions that fd's are legit for whatever you are doing. Or check LSM labels if the target is only linux.

@josh @bugaevc I mean with SCM_RIGHTS you can send a payload and the receiver can check uid/sgid and thus is often quite useful tool to do all sorts of handshakes within a single machine.

@josh @bugaevc what about using sgid as an identifier + SCM_RIGHTS? Not sure if it fits to the context, just.came to mind.

@bugaevc @josh thanks for educating, nice to learn details like this, appreciate it :-) i had no idea tbh. just thought that a test program could help out with the question

@josh

So you mean like (words can mix up stuff):

#include <sys/stat.h>
#include <sys/types.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>

int main(int argc, char **argv)
{
	char *line = NULL;
	struct stat sb;
	size_t len;
	int fds[2];
	pid_t pid;
	ssize_t n;
	if (pipe(fds) < 0) {
		perror("pipe");
		exit(1);
	}
	pid = fork();
	if (pid < 0) {
		perror("fork");
		exit(1);
	}
	if (pid == 0) {
		dup2(fds[1],  STDOUT_FILENO);
		close(fds[0]);
		close(fds[1]);
		if (fstat(STDOUT_FILENO, &sb) < 0) {
			perror("fstat");
			exit(1);
		}
		printf("child: st_dev=%u, st_ino=%llu\n", sb.st_dev, sb.st_ino);
	} else {
		dup2(fds[0],  STDIN_FILENO);
		if (fstat(fds[1], &sb) < 0) {
			perror("fstat");
			exit(1);
		}
		printf("parent: st_dev=%u, st_ino=%llu\n", sb.st_dev, sb.st_ino);
		close(fds[0]);
		close(fds[1]);
		n = getline(&line, &len, stdin);
		if (n < 0)  {
			fprintf(stderr, "Unexpected EOF\n");
			exit(1);	
		}
		fwrite(line, n, 1, stdout);
		free(line);
		wait(&pid);
	}
	exit(0);
}

? With M1 generation MacBook Pro I get:

$ ./test
parent: st_dev=0, st_ino=9204210306621897207
child: st_dev=0, st_ino=9204210306621897207

Hyvä esimerkki tällaisesta lopputuotteesta on yli puoli miljoonaa riviä sisältävä SoC-suunnitteluohjelma Tampereen yliopistolta: https://github.com/kactus2/kactus2dev. Tuota voi pitää jopa edelläkävijänä joillain alueilla. Hatun nosto, että tuollaista on saatu aikaiseksi "siinä sivussa".

suomalainen #yliopisto-maailma kaipais enemmän praktiikka-työrooleja, eikä pelkkää #tutkija-urapolkua. se on mun näppituntuma tän tilapäisen spin offin aikana. jotkut tutkimusprojektit sisältää sen verran monimutkaisia ohjelmisto- ja rautalopputuotteita, että ihmiset joutuu hoitamaan tällaisia rooleja käytännössä väärällä virkanimikkeellä. se johtaa heikoilla prosesseilla toteutettuun kehitykseen, koska praktiikkaa tehdään ikäänkuin tiskin alta, koska se ei ole virallisesti tunnustettu maali samalla tavalla kuin itse julkaisut.

jos näin tehtäisiin, saataisiin parempaa laatua vähemmällä ajankulutuksella ja paineella, ja ihmiset saisivat parempaa tunnustusta käytännön sorvauksesta. vaikka työroolit aiheuttaa budjettiin lisäkustannuksia, koska silloin tekemisestäkin pitää maksaa parempaa liksaa, niin työtuntisäästöt vastaisivat varmasti useampaa kuin yhtä henkilötyövuotta per tutkimushanke. tässä ehkä katsotaan liikaa suoraa kustannusta, eikä mietitä epäsuoria kustannusvaikutuksia tarpeeksi.

@spubby ok thanks for sharing :-) it is sort of "how to exit vim" of helix

well, returned back safe #neovim. i did like experimenting with #helix tho and am going change my neovim configuration based on that. I’ve used vim for 25 years so pretty hard to get out of old habbits.

Some glitches that would need to be fixed before I would try it again:

1. Doing quick changes to tabbing was too much effort compared to something like set ts=2 sw=2 et. Creating a .helix directory for upstream projects in not always even an option.
2. I don’t like multiselect, totally useless and confusing feature to me, and the whole philosophy is based on this concept. I generally do not want the text editor to be too symbol aware to the point that it gets in the way. This is actually why I never got into Emacs. It is way too smart editor for me :-)
3. I was not able to format (gq) email paragraphs when responding with aerc.
4. No remote editing so not very nice to use with tmux. I usually open my files from command-line, not from the editor.
5. Probably just user incompetence but I did not know how to exist from that stupid multi-select once I had done search replace. So I exited the whole editor after every single search-replace.

In producing code it is not very important how fast you can write the code because 95% of time goes to QA anyway and making first functional version to actually work with real workloads. So personally I think that new editors optimize a local maximum that does not help to deliver all that much as you might first think.

@harrysintonen For uneducated person on these attacks like me, the best protection has been to stick to text based email clients :-) Haven’t had an issue to separate a phishing email from legit when I read all my email previously with mutt and these days with aerc.

I would have no chance to survive from these or notice them if I used Outlook/Thunderbird or similar :-)

@dpom @nnethercote I've worked on systems programming for my whole career so take my opinions from that angle. I'm specifically talking about code that would end up to kernel, bootloader, firmware, systems service etc. Do not mean to discriminate :-) I think Rust is great because it provides equal platform to work teams that do different areas of software and still get stuff easily integrated.

@dpom @nnethercote Thanks, was aware of this book!

For async in particular the real mechanics are sort of “hidden” given the frameworks that put them nicely on the plate (such as tokio). For that it makes sense for anyone to see how it is “open-coded” just to not feel unsafe when putting weird keywords to the code.

I was a bit lost with that in particular until I read a chapter from book “Rust of Rustaceans”, which has pretty nice explanation of what it actually is: a polling interface and (usually) a thread pool (i.e. “executor”). All the syntax is semantically just macros with language level syntax to place them.

This is how I open Rust concepts. They are either new functions or code generators in some sense. If the latter I just do the exercise of open coding the generator to see what it results in.

It is quite common theme in new Rust language features that they are just code generators that produce a “normalized” subset of “plain” Rust code. By understanding this it takes a lot of magic away and helps to understand what they actually achieve.

@davesh For sure but yeah right now the only go is to read/write for Poylend projects themselves and place it in appropriate data structures for further use :-) I already have instrument reader but nothing I would publish right now. As soon as I get song structured I spin off a Github repository.

I'm implementing crate for reading (and later on writing) #polyend #tracker projects :-) Not proactively developed until I get my serial tool in shape tho. After I have that I might write a playback engine for the projects and a command-line player. For reverse engineering reverb and delay algorithms I'm going to use Bitwig Grid and then just compare sampled output until I get it right.

The utility would be e.g. to convert Polyend project to #Bitwig or #Ableton project and stuff like that but to do proper conversion you first need to have a playback engine for comparative testing even though those tools do no need to play anything.

Theoretically I wonder how feasible it would be to generate some HDL and software from same Rust code base. Borrow checker and lifetime parameters give already a framework for that purpose so I guess it could be theoretically possible. #rustlang #vhdl #verilog

Cool apparently got first PR to zmodem2 crate. Now I have an open source community, quality replace quantity I hope :-)

Found one promising: https://github.com/smol-rs/polling. So I'll give it a shot.