# Unified structure for sampled signals

**URL:** <https://discourse.julialang.org/t/unified-structure-for-sampled-signals/59977>\
**Category:** Community\
**Created:** [April 25, 2021, 8:43am UTC](https://discourse.julialang.org/t/unified-structure-for-sampled-signals/59977 "2021-04-25T08:43:58Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![TheLateKronos](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/thelatekronos/32/12824_2.png) [@TheLateKronos](https://discourse.julialang.org/u/TheLateKronos)\
**Post date:** [April 25, 2021, 8:43am UTC](https://discourse.julialang.org/t/unified-structure-for-sampled-signals/59977/1 "2021-04-25T08:43:58Z")

</div>

So I have seen the package [JuliaAudio/SampledSignals.jl](https://github.com/JuliaAudio/SampledSignals.jl), which aims to  
“… be used on multichannel sampled signals like audio or radio data, EEG signals, etc., to provide better interoperability between packages that read data from files or streams, DSP packages, and output and display packages”.

I think this sounds great. I have, however, heard from a couple of individuals that they are not fans of building on top of its structure, as mentioned in two comments in [this discussion](https://github.com/JuliaAudio/PortAudio.jl/issues/54).

So, I wanted to open up a larger constructive discussion with the aim of figuring out:

1. Would a unified underlying structure be nice when working with sampled signals?
2. Is it worth a dependancy?
3. If yes, what could `SampedSignals.jl` do better to fill this need?

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [April 26, 2021, 12:01pm UTC](https://discourse.julialang.org/t/unified-structure-for-sampled-signals/59977/2 "2021-04-26T12:01:17Z")

</div>

> [@TheLateKronos](#):
>
> I wanted to open up a larger constructive discussion

I think that the discussion you linked is very specific to that particular package, and maybe it would be better to discuss it in an issue. Issues tied to a package are easier to discover and have a higher chance of being addressed.