Wrap AbstractArray rather than Array in SampleBuf?

[mchitre]

Currently SampleBuf wraps an Array. This disallows wrapping of views or other array-like data types, for example. Is there any strong reason why not wrap an AbstractArray instead?

[mchitre]

Fixing this might allow nice adding constructs like @view buf[pos1:pos2] for buf::SampleBuf to also be a SampleBuf, and therefore retain sampling rate metadata.

[mchitre]

I've implemented this for testing, and seems to work well:
mchitre@2b72081

If you don't see any problems with this change, and are open to it, I can raise a PR.

[ssfrr]

Yeah, I don't have any problem with that at all, seems like a good improvement.

For your view example you'd have a SampleBuf that wrapped a view into the original data, right?

[mchitre]

Correct

[ssfrr]

Great, that's quite nice. Thanks!

[ssfrr]

Also note that changing this view behavior would be a breaking change, so I'll add it to the list for the next breaking release.

[mchitre]

I've included the AbstractArray change in the same PR, as it is quite minor. I'll do a separate PR later for the @view change, once I've implemented, tested and am happy with it being robust.

[haberdashPI]

I think I did something similar with the large PR I wrote a while back, might be worth checking in there to see if there's anything else you want to use.

[mchitre]

Actually turned out to be simple enough. I've added it to the same PR but in a different commit (in case you want to release them in separate version). I've added a test case to cover it too.

[mchitre]

I realize that wrapping an AbstractArray may not be such a good idea for type inference [1]. I haven't thought through this fully, and figured it was better to drop this from the PR until the best design approach discussed/explored.

[ssfrr]

Yeah, rather than actually wrapping AbstractArray the wrapped type should be given as a type parameter. Otherwise indexing etc. will be very slow.

[mchitre]

Yup. But since this is encoded in AbstractSampleBuf{T,N}, the implications of re-parametrizing for the remaining code base may be substantial.