On Mon, Oct 28, 2013 at 9:00 AM, Aurélien Leblond <blablack@gmail.com> wrote:
>> In my lv2 plugin, I need to communicate information from the DSP to
>> the UI, but I don't want to break the DSP/UI separation principle (no
>> Instance or Data access). On top of that, I'm using LVTK.

> he, he, yeah it can get a little confusing... maybe this will help.
>    // you're sending things in an atom sequence so get the size information
>    // from the port buffer
>
>    LV2_Atom_Sequence* aseq = (LV2_Atom_Sequence*) p (p_notify);
>    m_forge->set_buffer ((uint8_t*) aseq, aseq->atom.size);
>
>    m_forge->sequence_head (m_notify_frame, 0);
>
>    // sequences need a timestamp for each event added
>    m_forge->frame_time (0);
>
>    // after forging a frame_time, just write a normal float (no blank object needed)
>
>    m_forge->write_float (1604);

> Your ttl file has  atom:Float  as the buffer type.  I've never used
> anything besides atom:Sequence.  I imagine this buffer type doesn't need a
> sequence head forged first.  Maybe David will jump in on how atom:Float
>  bufferType'd  ports are supposed to forged into and out of.

Ok, so I changed my code the way you proposed (with switching in the
ttl to Sequence), but still don't manage to make it work.
I'm wondering if there isn't something wrong with the way I setup the
Forge in the first place. I'm a bit confused with the way to interact
wiith the map object in LVTK.

   Scope::Scope(double rate) : Plugin<Scope, URID<true>,
Options<true>>(p_n_ports)
   {
       m_forge = new AtomForge(p_map);
   }


The map object is 'just there' for when you need it, like creating new forges ;)  I've always wondered if it made more sense  to provide a accessor method to it for clarity   Plugin::get_urid_map() const   or something like that.

That looks right for creating a forge, AtomForge's  ctor will call lv2_atom_forge_init
when the map is passed in (just like you do above)
 
   void Scope::run(uint32_t nframes)
   {
       // you're sending things in an atom sequence so get the size information
       // from the port buffer

      LV2_Atom_Sequence* aseq = (LV2_Atom_Sequence*) p (p_notify);
      m_forge->set_buffer ((uint8_t*) aseq, aseq->atom.size);

       m_forge->sequence_head(m_notify_frame, 0);

       // sequences need a timestamp for each event added
       m_forge->frame_time(0);

       m_forge->write_float(1604);
   }


Still nothing happening on the GUI end ay?  Could I just have a link to the full source code?  I'm better debugging hands on.  Sorry, I can't recall the git address to your plugin set.

Forging atoms (in a way that actually works) isn't by any means a straight forward process.

 

> I recommend, if you want to use LVTK to do atom forging, that you subclass
> lvtk::AtomForge and add appropriate methods to it...
>
> Here's a snippet that shows how to write  patch get/set messages with a
> subclassed AtomForge.  It also shows how to write raw midi.
>
> http://pastebin.com/C1LYtXpv  --  the code in there uses small uses the
> nullptr macro.  just change those to "0"  if you're not using c++11

Could you tell me the advantages of doing that?

1)  AtomForge inherits LV2_Atom_Forge directly.  This makes it possible to use this class as if it were a regular c-typed forge..    e.g ...
   
    AtomForge* forge = new AtomForge (this->p_map);
    lv2_atom_forge_float (forge, 45.0f);

.... would work.  It makes it possible to do custom forging using the normal LV2 Atom API if wanted

2)  By inheriting and adding to it keeps all of your forge'ing related code organized into one place.  Its a nice thing to do if you're not into writing the same lines of code over and over again.

So I suppose its a personal preference kind of thing.  Personally, once I discover how to write a particular atom type correctly, I like to save it and not have to figure it all out again.


But I had a look at the code, I still need to understand how to work
with LV2_URID_Map in LVTK (I cannot find any examples using it).