On Mon, Oct 28, 2013 at 9:00 AM, Aurélien Leblond <blablack(a)gmail.com>wrote;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).