You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to propose the addition of a function
NPipe(vSrc, vSnk Form, n int, p func(snkd, src []float64) error) (src Source, snk Sink)
which would
act like pipe, except
the Form of src would be vSrc
the Form of snk would be vSnk, and hence could differ
calls to src.Receive and snk.Send would return an error if the block size were not n
the function p, if not nil, would be called on every []float64 sent through the pipe and
if it resulted in an error, then that error would be returned to both the source and sink side.
If p is nil, and vSrc.Channels() != vSnk.Channels(), then a non-nil error would be returned.
If p is nil, and vSrc.Channels() == v.Snk.Channels(), then it would effectively pass through
the data without error.
This would
allow a developer to easily guarantee synchonized buffer sizes, and have corresponding efficiency benefits
allow for easy dynamic resampling and channel mapping and what not without needing to multiplex i/o beyond 1 input and 1 output.
Thoughts appreciated.
The text was updated successfully, but these errors were encountered:
I would like to propose the addition of a function
which would
act like pipe, except
if it resulted in an error, then that error would be returned to both the source and sink side.
If p is nil, and vSrc.Channels() != vSnk.Channels(), then a non-nil error would be returned.
If p is nil, and vSrc.Channels() == v.Snk.Channels(), then it would effectively pass through
the data without error.
This would
Thoughts appreciated.
The text was updated successfully, but these errors were encountered: