Re: [LAD] [LV2] LV2: Communicate from the DSP to the UI

2013-11-10 Thread Aurélien Leblond
   I've just brushed it up a bit, removed all raw-atom write calls,
added
   RDF attributes for channel-id, etc and also sanitized the drawing
   routine somewhat. pushed to
  
 https://github.com/x42/sisco.lv2
  
   Now it is a proper example and should be about halfway towards your
needs.
 
  Perhaps a good candidate for official (i.e. included) example?

 eg-scope, sure, fine with me; but please give me a few days to add some
 more comments to the source: elaborate on Atom-msgs and clearly note
 that the scope display itself is horribly wrong design. It's actually a
 perfect textbook example of what *not* to do:

 * no thread sync. it redraws somewhat randomly
 * it's neither accurate nor stable
 * it displays raw samples (a proper scope should^Wmust not do that)
 * the display itself just connects min/max line segments
 * no labels, no scale, no calibration
 * ...

 maybe Aurélien is going to address some of these issues, and his project
 will eventually be suited better for inclusion as official example.

Probably not suitable, as I'm using the LVTK wrapper.

 Alternatively removing the drawing routine would IMHO be appropriate for
 an example atom-vector communication plugin.

 @Aurélien: are you planning to implement a trigger mechanism and/or
 history? any plans to add up-sampling and interpolation? what about
 markers and numerical readout?

It is a port of the dssi ll-scope:
- trigger mechanism for redraw
- no up-sampling or interpolation I could find in the code, but I could be
wrong there as I didn't dig that deep yet into the gtk widget code
- it has markers but no numerical readout
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] [LV2] LV2: Communicate from the DSP to the UI

2013-11-10 Thread David Robillard
On Sat, 2013-11-09 at 21:33 +0100, Robin Gareus wrote:
 On 11/09/2013 08:10 PM, David Robillard wrote:
 https://github.com/x42/sisco.lv2
  Perhaps a good candidate for official (i.e. included) example?
 
 eg-scope, sure, fine with me; but please give me a few days to add some
 more comments to the source: elaborate on Atom-msgs and clearly note
 that the scope display itself is horribly wrong design. It's actually a
 perfect textbook example of what *not* to do:
 
 * no thread sync. it redraws somewhat randomly
 * it's neither accurate nor stable
 * it displays raw samples (a proper scope should^Wmust not do that)
 * the display itself just connects min/max line segments
 * no labels, no scale, no calibration
 * ...
 
 maybe Aurélien is going to address some of these issues, and his project
 will eventually be suited better for inclusion as official example.
 
 Alternatively removing the drawing routine would IMHO be appropriate for
 an example atom-vector communication plugin.
 
 @Aurélien: are you planning to implement a trigger mechanism and/or
 history? any plans to add up-sampling and interpolation? what about
 markers and numerical readout?

I meant the generic idea of trucking stuff via messages for
visualizations, not so much this specific implementation.  For the
purpose of an LV2 example, though, many of these aren't so important.
It's more about showing the structure than an actually decent scope.

Maybe a really simple meter would be a better one though.

Anyway, no rush with me these days, as usual :)

-- 
dr


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] [LV2] LV2: Communicate from the DSP to the UI

2013-11-09 Thread Robin Gareus
On 11/09/2013 08:10 PM, David Robillard wrote:
  I've just brushed it up a bit, removed all raw-atom write calls, added
  RDF attributes for channel-id, etc and also sanitized the drawing
  routine somewhat. pushed to
  
https://github.com/x42/sisco.lv2
  
  Now it is a proper example and should be about halfway towards your needs.

 Perhaps a good candidate for official (i.e. included) example?

eg-scope, sure, fine with me; but please give me a few days to add some
more comments to the source: elaborate on Atom-msgs and clearly note
that the scope display itself is horribly wrong design. It's actually a
perfect textbook example of what *not* to do:

* no thread sync. it redraws somewhat randomly
* it's neither accurate nor stable
* it displays raw samples (a proper scope should^Wmust not do that)
* the display itself just connects min/max line segments
* no labels, no scale, no calibration
* ...

maybe Aurélien is going to address some of these issues, and his project
will eventually be suited better for inclusion as official example.

Alternatively removing the drawing routine would IMHO be appropriate for
an example atom-vector communication plugin.

@Aurélien: are you planning to implement a trigger mechanism and/or
history? any plans to add up-sampling and interpolation? what about
markers and numerical readout?

best,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] [LV2] LV2: Communicate from the DSP to the UI

2013-11-05 Thread David Robillard
On Mon, 2013-11-04 at 23:48 -0600, Michael Fisher wrote:
 On Mon, Nov 4, 2013 at 6:52 AM, Aurélien Leblond blabl...@gmail.com wrote:
 
  Hi Michael,
 
 
  What I think I should be doing is using Blank Atom to transfer the
  data from DSP to UI, right?
 
 
 It sounds logical to me, yeah.  Doing it this way could be done by forging
 the Blank atom and then writing the float array as raw.   You would need to
 map a few uris specifically for this to use inside of the blank object.
 
 seems like peak proptocol etc etc.. would could also be used here.  I don't
 think there's a single host that supports any of those kinds of features
 though

Bit of a tangent, since this is just host internal (i.e. non-plugin)
stuff, but the blinkenports/meters in Ingen work this way.  It actually
works surprisingly well across processes or even a network, though the
current simplistic design (message per port) doesn't scale up to a ton
of ports very well.

-- 
dr


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev