using JACK on all OSes just isnt feasable for something like what we are talking about
using JACK on all OSes just isnt feasable for something like what we are talking about
Lwe'd have to have per platform backends
Kmaking a dotnet library as a nuget package that requires end users of the dependant application to install something separate is bad if it isnt necessary for the idea
C@Perksey I've been playing with a pointer type idea: https://codeshare.io/j09BO3
This would allow for
While we would lose out on implicit overloads for mutidimensional, those could be added in as functions using extensions with where clauses, or specific types, to allow for more depth specific functions.
This would allow for
PointerToConst<Pointer<byte>> byteArray; // byte*const*While we would lose out on implicit overloads for mutidimensional, those could be added in as functions using extensions with where clauses, or specific types, to allow for more depth specific functions.
Mi was just wondering why you mentioned JACK earlier
Llinux
Mwe talked about this one time before :D
never figured out whether or not to use it though
never figured out whether or not to use it though
Mor why not
Lalso if you actually read my message i said "i wish it was better integrated on non-linux OSes"
Lsince if it was
Litd be a good choice
Moh, but why is JACK good on linux then
Mi'm out of the loop
Lits integrated directly into pipewire nowadays
Mhmm i see
Lbasically every modern linux system has a JACK server built right in and perfectly integrated into the audio stack
Moh awesome
Mmy wife is a jack hater i need to tell her that
Lfrankly you may need to rethink your marriage if they dislike such a good audio API
Mshe uses windows.
Mneed i tell you about the jack GUIs on windows
Meven i don't understand it and i use audio mixing software
M"oh, it's like jacks" but then you've got 3 different windows that do different things
Li just use qpwgraph to manage all my JACK connections
Lbut thats linux only :^)
Mfuck
Lthis same interface should be in qjackctl tho
Lit is
L"Graph" is the button
Mlarge sharplab url improved
C#/VB/F# compiler playground.
CThanks 
Mlarge sharplab url improved again
C#/VB/F# compiler playground.
Midk if this like, works tho
Mnever tested it in practice
Mmaybe there's some screwed up GC behavior that collects the ref before it should, or something
Mi mean, this is a struct that behaves like a ref struct, so if it's stored in a non-ref type, it might be fucky wucky
Mmaybe an analyzer could catch that
Msomething something silk is unsafe
CIt shouldn't it is no different from storing an int. You should be able to store it in another struct.
Kyeah this loses the ref safety from ref structs in exchange for allowing the syntax we wanted in the first place without the limits on using them as ref fields
Vshrimpcat#0000
otherwise how do you differentiate Get on PtrType<T> vs Get on PtrType<Ptr<T>>
Original Message
Quoted by perksey#0000
Mi can't even remember what i meant
Mactually
Mthat was a problem with that design
Mthis design is ref-less
Mshouldn't be a problem
Mwe could just live with that
Mwhat was the benefit of using the Ptr wrapper over T* again
Mwas it specifically for ref safety
