also if you actually read my message i said "i *wish* it was better integrated on non-linux OSes"
also 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
Pbut
Mthat was the thing i was thinking
Mbut if you can only make a Ptr to unmanaged types
Pyou’d have to force users to use fixed
Pand at that point just use raw pointers
Mhm.
Myeah