[Clam-devel] GSoC, patch and questions...

[Pau Arumí]

El dc 23 de 04 del 2008 a les 12:59 -0300, en/na Natanael Olaiz va escriure:
> El 04/23/2008 12:01 PM, Pau Arumí escribió:
> > El dt 22 de 04 del 2008 a les 19:43 -0300, en/na Natanael Olaiz va
> > escriure:
> >   
> >> Hi!
> >> To start learning the CLAM platform, Pau gave me this advice:
> >>
> >>     If you want to take a small useful
> >>     task, here goes one: "add Source/Sink by right clicking to a out/in
> >>     audio port ". It shouldn't be very hard since taking the add-monitors as
> >>     example. You can start with tentative code, that you can send as patches
> >>     and we'll comment.
> >>       
> >>
> >> I did it partially (copying and pasting...), in a half way: to connect 
> >> the objects outputs to the AudioSink (I attached the patch file). But it 
> >> have a problem: it allows ALL TYPES output signals to connect to the 
> >> AudioSink.
> >> I copied the monitor implementations, which search the monitors with the 
> >> same type than the output, doing: "factory.GetKeys("port_monitor_type", 
> >> outportTypeId(_processings[i]->model(),portindex))".
> >> But I didn't found any similar descriptor (than "port_monitor_type") for 
> >> the input/output audio slots, so I used: "keys = 
> >> factory.GetKeys("description","AudioSink")" to search the AudioSink(s) 
> >> object(s), but without taking care to match the data types...
> >>     
> >
> > Hi Natanael, 
> >
> > i'm very happy to receive this early patch :-)
> > Let's keep working on it:
> >
> > The onAddOutput() method is ok, just rename it to onAddSink()
> >
> >   
> Is correct to still using a call for "addPortMonitorProcessing(...)" 
> whithin there?

Good point! Now its semantic gets more general, so better rename it to
addLinkedProcessing(...)


> >> Then my questions are:
> >>     - Using GetKeys("description","AudioSink") is a good way to match 
> >> those objects?
> >>     
> >
> > No, this is not necessary -- and neither the iteration on keys. As
> > simple as adding the action with a given description
> > menu->addAction( "Link with Audio
> > Sink",this,SLOT(onAddOutput()))->setData(translatedPos);
> >   
> Ok.
> >>     - There is a descriptor similar to "port_monitor_type" for 
> >> input/output audio slots? If yes, where I can found it?
> >>     - What is the better way to check the data types? (I think the 
> >> actual patch with a conditional could works..)
> >>     
> >
> > Ok, filtering by type is the tricky part. Look at the tip 8 lines above
> > your code:
> >
> > Keys keys = factory.GetKeys("port_monitor_type",
> > outportTypeId(_processings[i]->model(),portindex));
> >
> > This returns all the processing factory keys that have an attribute
> > "port_monitor_type" with value SomeType. Where SomeType is the clicked
> > port type. 
> >
> > So this is what you need to call:
> > outportTypeId(_processings[i]->model(),portindex))
> > this returns and string. Experiment (for example printing it out) to
> > find which is the string corresponding to an Audio type. With that
> > you'll be able to add the needed "if".
> >   
> 
> Great, and simple! :) I was just wondering how to match it with a key, 
> but if make the direct connection I only need to test the output type 
> and allow (or not) to do it....
> 
> > If you add icons (even VERY draft ones) and the Source part, this will
> > be a wonderful patch to contribute.
> >
> > Pau
> >   
> Ok, now I'm going to the University. When I'll return I'll try your 
> suggestions and make an icon. Do you like a speaker for it?

Yes! 
(first working version quick and refinements later)