Универсальное представление приборных сигналов

Sample : anything

Record
 - Sample[n]
 - Time0
 - TimeLast
 - parent: Signal

Signal
 - Record[n]
 - parent: Multichannel

Multichannel
 - Signal[n]
 - my Source
 - parent: Session

Session
 - Multichannel[n]
 - my attributes (patient? comments? soft versions? undo data? .....)

Source
 - my Nature
 - my Device
 - status, config, etc

Nature (enum: RawAudio, Envelope, IndexSet, Eeg, EmbolMarker, UserComment, ErrorEvent, ..........)

Device
  - map Nature[n] to array of InCom[n]
  - status, config, etc (variable)

InCom : abstract class
     InComExternal extends InCom
     InComSource extends InCom
            - my Source

Тогда Device может для разных своих Nature иметь либо внешние источники (InComExternal - как сырой звук или сообщения UI) либо внутренние источники заведенные на один из Source (InComSource - Spectrum from RawAudio, EmbolMarker from Spectrum+RawAudio, ...).

Это пока представление для нас самих. Как мы это будем закладывать в ЭВМ во всех аспектах это вопросы следующих уровней и разных проекций.

Речь тут не идет ни о протоколе, ни о структуре БД, не об UI, не об инкапсуляции а о трансцедентном, способном воплотится в конечные формы ограниченные, приземленные как есть они.

В классы это может проецироваться самыми разными способами. На практике каких то элементов не будет, какие то добавятся. Зависит от специфики приложения, аспекта (БД, UI, math, transfer...), уровня (impl, iface, ifacegp, SDK, javascript, ....) и т.п.

Главное чтобы любые представления сигналов понимали частным случаем какой концепции они являются, использовали общие термины и могли сообщаться и однозначно конвертировать информацию.

(вынести отсюда в Usee!)

Мне видется 2 пути:

1) Рисовалка предоставляет какой-то callback для приложения, которое знает что это за сигнал. Приложение дает необходимые данные для этой конкретной рисовалки. Бред мы же не хотим привязываться к конкретной рисовалке. Может тут какой MultipleDispatch пройдет через объект хелпер.

2) Сэмпл в интерфесе объявляет методы итерации себя в примитивах (int, num) и/или переключатель на один из этих методов.

И я пока абсолютно не представляю что тут можно оптимизировать и как при таких уровнях абстракции, но универсальность конечно гигантская.

А кто сказал, что рисовалке давать сэмплы нужно? Я ей весь сигнал дам и пусть она сама решает, как быстрее вывести. Рисовать ли по сэмплам, или прямоугольниками, а может полилайнами для скорости.

Сэмпл - тут абстракция, означающая минимальный размер объекта. В 3D это может быть и шарик, например, а не точка

— А что значит anything? В конечном итоге абстрактный painter должен нарисовать каждый семпл. Как он будет взаимодействовать с sample-ом.а если мы хотим целую кривую отрисовать? Зачем нам каждый семпл, если оптимизированно всю ее вывести хотим?

— И как ты себе это представляешь?Рисовалка ничего не знает о сигнале кроме того что он состоит из семплов.

Sample::
  GetNumAmplitude
  GetPositiveIntAmplitude
  GetBipolarIntAmplitude
  GetMainShortStr
  GetFullText
  GetContainedMultichanel
  GetSomethingElseMyOutputGeneratorCanRender
  QueryType

В конечном итоге абстрактный painter должен нарисовать каждый семпл.

— а если мы хотим целую кривую отрисовать? Зачем нам каждый семпл, если оптимизированно всю ее вывести хотим?

— Это отличный вопрос один из главных и сложных во всей концепции этих универсальных интерфейсов [не углубляясь в офтоп Usee / Udb]

Каждый интерфейс где существенно быстродействие должен понимать не только дискретные виртуально структурированные

 Record
 Signal
 Multichannel

но их их частные формы.

Если хранилище, рендерер, сендер, паковщик, обработчик понимают например array<short> (или CAudioSliceGp который надо глобализовать) то они должны предпочитать выбор этих частных случаев над более общим с виртуальными функциями (= очень медленными)

Не забываем что сигнал это не только array<int> но и список маркеров например, выводится может не только на экран но и экспортироваться во внешние форматы, хранится может не только в памяти но и в БД разного рода целиком, частично, в офлайн, в онлайн инкрементно

от

   DrawPolyline(a, nCount)

или

   rAudioSlice.AppendSlice(rSlice)

до

   ExportToExcel(aMarkerList)

или

   UpdateDb(keyNext, rNewEvent)

Т.е. если мы хотим нарисовать список маркеров как гистограмму, нам нужно сделать ковертор "Список маркеров" -> array<int> на каком-то уровне, правильно?

И потенциально нам нужно понатыкать конверторов "все что угодно" -> "во все что угодня для отрисовки конкретным Painter-ом".

UseeSample
{
  // до сих пор не понял кто определяет интрфейс Usee или приложение
}
 
USeeRecord
{
 
  // optimized access
 
  List<rgb> GetAsRgbColorArray();
 
  List<int> GetAsIntArray();
 
  List<xxx> GetAsXxxArray();
 
  private array<UseeSample> m_aUseeSample;
}
 
USeeSignal
{
  private array<UseeRecord> m_aUseeRecord;
}
 
UseeRender
{
   RenderSample(UseeSample);
 
   RenderRecord(UseeRecord);
 
   RenderSignal(UseeSignal);
}
 
UseePainterBitmap : USeePainter
{
    OnRenderRecord(UseeRecord record)
    {
        this->DoRender(
            record.GetAsRgbColorArray());
    }
}
 
UseePainterRtfTable : USeePainter
{
    OnRenderRecord(UseeRecord record)
    {
        this->DoRender(
            record.GetAsIntArray())
    }
}

Sample::
  GetNumAmplitude
  GetPositiveIntAmplitude
  GetBipolarIntAmplitude
  GetMainShortStr
  GetFullText
  GetContainedMultichanel
  GetSomethingElseMyOutputGeneratorCanRender

По сути это скорей не Get а Query то есть с возможностью узнать может ли данный семпл предствить себя в данном формате. Если он не может быть не int не num то все гистограммы по нему отпадают. 

Т.е. Usee определит универсальный интерфес на абсолютно все случаи жизни, которые им поддерживаются, а приложение будет выбирать, что из этого оно готово реализовать. Так?

Меня кстати вчера "лечили" что такой уровень декомпозиции ни к чему хорошему не приводит. Все будет жутко медленно и нельзя столько классов лепить 

Я где то выше писал что тут не про классы речь ведем.

А ниже писал что array<short> никто не отменяет, ничто не заменяет.