Wenn wir das mit der digitalen Unabhängigkeit ernst meinen ist #Signal einfach nur eine Ablenkung.
Uncategorized
3
Posts
2
Posters
2
Views
-
RE: https://social.tchncs.de/@restless/115912656588056648
Wenn wir das mit der digitalen Unabhängigkeit ernst meinen ist #Signal einfach nur eine Ablenkung.
#Quicksy hingegen ist ein wirklicher Schritt in die richtige Richtung. Quicksy ist so konzipiert, dass man darüber hinaus wächst und ein nahtloser Übergang zu #Conversations_im möglich ist.
Quicksy ist die Einstiegsdroge für wirklich unabhängiges Instant Messaging mit #XMPP. -
RE: https://social.tchncs.de/@restless/115912656588056648
Wenn wir das mit der digitalen Unabhängigkeit ernst meinen ist #Signal einfach nur eine Ablenkung.
#Quicksy hingegen ist ein wirklicher Schritt in die richtige Richtung. Quicksy ist so konzipiert, dass man darüber hinaus wächst und ein nahtloser Übergang zu #Conversations_im möglich ist.
Quicksy ist die Einstiegsdroge für wirklich unabhängiges Instant Messaging mit #XMPP.@daniel ich finde es schade, das so gegeneinander auszuspielen. Klar, besser als Signal geht, das ist keine Frage. Aber um die Leute möglichst zügig von Whatsapp etc. wegzubekommen doch nicht schlecht, oder?
Warum nicht "hey, Signal ist nicht schlecht, wenn du mehr willst: hier"?
-
@daniel ich finde es schade, das so gegeneinander auszuspielen. Klar, besser als Signal geht, das ist keine Frage. Aber um die Leute möglichst zügig von Whatsapp etc. wegzubekommen doch nicht schlecht, oder?
Warum nicht "hey, Signal ist nicht schlecht, wenn du mehr willst: hier"?
@griesgram Wenn das Ziel ist die Leute von WhatsApp wegzubekommen bin ich d'accord damit.
Der Anspruch war aber digitale Unabhängigkeit und da ist Signal einfach Thema verfehlt.
Digitale Unabhängigkeit bekommen wir nur hin wenn wir das selbstständig in unseren jeweiligen communties organisieren. Unabhängigkeit erlangt man nicht in dem man sich von einem walled garden in einen anderen walled garden mit etwas weniger Dornen begibt.
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@shinmera that's fine. all of the linux audio applications that will ever exist have already been written
-
@sixohsix @mcc I would be shocked if RtMidi has a solution for this that isn't sweeping it under the rug and hoping nobody notices. MIDI is the old half-abandoned mall inside your computer.
-
@sixohsix @mcc but ALSA insists that there is a "now", and that "now" is a thing that is real and exists, and has a clock and that clock moves forward in fixed increments, and never throttles, and so on. ALSA, despite also having this concept of batched time in its audio processing model i'm pretty sure, does not seem to believe that midi would ever be processed precisely, or need a be sieved in ~0.02 second chunks.
-
È nelle stazioni di Luciano Erba (Milano, 1922 – Milano, 2010)
È nelle stazioni ferroviarie
dove fili attraversano fili
tesi in alto tra pali e vetrate
è nelle grandi stazioni ferroviarie … https://cctm.website/luciano-erba-italia/#LucianoErba #stazione #poesia #cctmwebsite #anoipiaceleggere #leggere
-
@sixohsix @mcc not in a random userland thread at any rate. time is stretchy. now, the audio thread as it happens is a lot more precisely timed than regular threads, and you can say ah, I'm currently processing ticks N through N + 1024, where a tick is exactly 1/48000 sound card seconds.
-
@sixohsix @mcc this is probably fine in most cases since the events are expired as soon as they're created anyway. a midi packet is HOT HOT HOT and should be processed ASAP anyway. But WHERE is "now"? do you have a clock that if you sample it and then sample it again a second later will give you exactly a second of time between the two samples? no. you do not.
-
@sixohsix @mcc in theory you could build a sequencer that does the same thing as what alsalib does under the hood in the first scenario, but as far as I can tell you can't actually read a common reference point for a given event's time offset, so for all intensive porpoises you only have one time point for everything in both cases: "now".
-
@sixohsix @mcc option 2: you tell alsa you do not care about time stamps: alsa leaves the time stamps in messages as they were recorded if they have them. god help you if you have multiple MIDI streams feeding the same port, because they will either have "realtime stamps" which are time points relative to that the output queue that event was written to, or they will be in "ticks" which is the same thing except the duration is variable
