frankly you may need to rethink your marriage if they dislike such a good audio API
frankly 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
Mi see it
Mand we can't do the thing that Span<T> did before ref fields, because that also had problems, i imagine
CThe main purpose for this was to handle slimming our overrides down.
Pthat was essentially a ref field before the language caught up
Ma wrapper that can handle both pointers and arrays
CIf we wanted to avoid making users use fixed, we could have a constructor that would allow them to allocate unmanaged memory, and then dispose it. behind the scenes.
Kwhat span did before ref fields was an intrinsic that behaved like a ref field that got substituted out by the runtime
Mbad idea
Cyeah not my favorite idea, but it would avoid the need for fixed statements.
Pyou can technically achieve what Span.DangerousCreate did before it was removed by calculating the ref offset from its owning object, creating a GCHandle to the object that owns the ref, and then reapplying that offset
