I’m trying to create a custom audio sink plugin for gstreamer using the Gst::AudioSink as a base class. For me this involves multiple learning curves as I’m new to gstreamer, gstreamermm and gobject. Also I have no background or real interest in gtkmm as I’m not working on GUI code at present.
I am trying to create a class along the lines of:
class MyAudioSink: public Gst::AudioSink
{
public:
explicit MyAudioSink(MyAudioSink *gobj);
virtual ~MyAudioSink();
static void class_init(Gst::ElementClass<MyAudioSink> *klass);
virtual int write_vfunc(gpointer data, guint length) override;
virtual void reset_vfunc();
};
I seem to missing some magic in the class_init() function that should link the base class functions to the virtual functions in MyAudioSink.
In C we would do something like:
GObjectClass *gobject_class = G_OBJECT_CLASS (klass);
GstAudioSinkClass *audio_sink_class = GST_AUDIO_SINK_CLASS (klass);
audio_sink_class->write = GST_DEBUG_FUNCPTR (myaudiosink_write);
I don’t really grok the C++ binding to gobject.
What is the equivalent for linking to the C++ virtual function hierarchy?
I got the impression from Marcin’s video https://gstconf.ubicast.tv/videos/gstreamermm-c-way-of-doing-gstreamer-based-applications/ that the virtual functions should be invoked automatically.
I can create a half usable (doesn’t handle things like EOS) plugin by adding:
add_pad(sinkpad = Gst::Pad::create(get_pad_template("sink"), "sink"));
sinkpad->set_chain_function(sigc::mem_fun(*this, &MyAudioSink::chain));
But I don't think a sink should have a chain function.
I've also asked this question on the gtkmm mailing list. If I get an answer there I will post it here.
For MyAudioSink I get a class hierarchy of:
GObject +----GInitiallyUnowned
+----GstObject
+----GstElement
+----myaudiosink
Rather than:
GObject +----GInitiallyUnowned
+----GstObject
+----GstElement
+----GstBaseAudioSink
+----GstAudioSink
+----myaudiosink
I suspect this is the essence of my problem.
For the audiofilter example Marcin mentions here I get a class hierachy of:
GObject +----GInitiallyUnowned
+----GstObject
+----GstElement
+----GstBaseTransform
+----GstAudioFilter
+----myaudiofilter
You can find examples of writing your own plugin in the repository: https://git.gnome.org/browse/gstreamermm/tree/tests/plugins/derivedfrombasetransform.h
In general, your header looks ok, and full implementation should look (more or less) like that:
class MyAudioSink: public Gst::AudioSink
{
public:
explicit MyAudioSink(KantarAudioSink *gobj)
: Glib::ObjectBase(typeid (MyAudioSink)),
Gst::AudioSink(gobj) {}
static void class_init(Gst::ElementClass<MyAudioSink> *klass)
{
// Y
klass->set_metadata("longname", "classification", "description", "author");
klass->add_pad_template(Gst::PadTemplate::create("sink", Gst::PAD_SINK, Gst::PAD_ALWAYS, Gst::Caps::create_any()));
}
virtual int write_vfunc(gpointer data, guint length) override {}
virtual void reset_vfunc() {}
};
Very recently we had a bug report when someone posted very nice, tiny example of audiofilter plugin, you can use it as an example for your project as well: https://bug794249.bugzilla-attachments.gnome.org/attachment.cgi?id=369564
If this doesn't work, feel free to file a bug here: https://bugzilla.gnome.org/enter_bug.cgi?product=gstreamermm
It turns out that much of my troubles were caused by cutting and pasting
this into MyAudioSink class:
static GType get_base_type()
{
return Element::get_base_type();
}
This had the effect of telling gobject that my class is based on gstElement which was wrong.
I thought it was some innocent cast like incantation.
This shows the perils of cut and paste but more than that the perils of coding blindly.
I was also guilty of oversimplifying the sample code I pasted here such that no-one my question doesn't show the problem.
That fixes my problem but does not answer my question.
I will try to summarise that below.
"What is the equivalent for linking to the C++ virtual function hierarchy?"
To create a wrapper to a gobject class the normal process is to use glibmmproc.
The wrapper is defined by files with extension .hg and .ccg from which the C++ interface and a gobject wrapper are generated.
For example to wrap a gobject classs foo you might create Foo.hg and Foo.ccg.
glibmmproc would then generate Foo.h and Foo.cc.
Foo.cc includes most of your definition of the Foo class but with
an additional gobject wrapper Foo_class.
Foo_class is a gobject class which wraps gobject virtual functions (vfunc_callbacks) and forwards them to Foo
allowing derived classes of Foo to use C++ inheritance and C++ virtual functions.
The boilerplate is hidden and a C++ developer need for the most part only worry about the C++ interface provided by Foo.h
One way to understand the internals is to build gstreamermm from source and study the code generated by glibmmproc.
For my case this would be: gstreamermm/audiosink.cc & gstreamermm/audiosink.h generated from
src/audiosink.ccg and src/audiosink.hg
So how does the derived C++ class register itself?
Gst::ElementFactory::register_element() - registers the class with gstreamer
Gst::register_mm_type - records the inheritance relationship
See your local /usr/include/gstreamermm-1.0/gstreamermm/register.h for the implementation
Glib::ObjectBase(typeid (MyAudioSink)) is not required in my case as I am not using multiple inheritance. However it is critical in other applications which do. See for example Implementing a custom gtkmm treemodel
Related
In a C++ cross-platform library,
we use shared headers which are compiled with different module versions for each OS.
A.k.a Link-Seam
//Example:
//CommonHeader.h
#ifndef COMMON_HEADER_H
#define COMMON_HEADER_H
class MyClass {
public:
void foo();
}
#endif
.
//WindowsModule.cpp
#include "CommonHeader.h"
void MyClass::foo() {
//DO SOME WINDOWS API STUFF
printf("This implements the Windows version\n");
}
.
//LinuxModule.cpp
#include "CommonHeader.h"
void MyClass::foo() {
//DO SOME LINUX SPECIFIC STUFF HERE
printf("This implements the Linux version\n");
}
Of course, in each build you only select one module, respective to the environment you are using.
This is meant to suppress the indirect call to the functions
My Question is: How to note this relationship in UML ?
"Inheritance"? "Dependency"? "Note"?
class MyClass {
public:
void foo();
}
This is nothing more than a class contract, so basically an interface which you realize in different modules. To visualize that, you can use interface realization notation (like a generalization, but with dashed lines).
The reality is I think that you’ve got only one class in a UML class diagram, being MyClass, with a public operation foo(); it’s just that you have two code implementations of this class, one for Linux and one for Windows. UML Class models are not really setup to answer the question of how you implement this, in your case using c++ with header files: Imagine if instead you in-lined your functions and ended up writing two inline implementations of MyClass, one for Linux and one for Windows. Logically you still have one class in your class diagram (but with two implementations) and the header file (or lack thereof) wouldn’t come into it. What you need therefore is a way to show a how the C++ is structured, not a way to show the logical class constructs. I’m not aware of a specific way in UML to represent code structure, however you could build a code structure model using Artefacts maybe (?) which could denote the c++ file structures.
It could be seen as some kind of "inheritance". There is however no relation between classes as there is just one class - so there is no relation between two. The actual construct of using platform dependent implementation however imitate relation "is a".
I hesitate to ask this question, because it's deceitfully simple one. Except I fail to see a solution.
I recently made an attempt to write a simple program that would be somewhat oblivious to what engine renders its UI.
Everything looks great on paper, but in fact, theory did not get me far.
Assume my tool cares to have an IWindow with IContainer that hosts an ILabel and IButton. That's 4 UI elements. Abstacting each one of these is a trivial task. I can create each of these elements with Qt, Gtk, motif - you name it.
I understand that in order for implementation (say, QtWindow with QtContainer) to work, the abstraction (IWindow along with IContainer) have to work, too: IWindow needs to be able to accept IContainer as its child: That requires either that
I can add any of the UI elements to container, or
all the UI elements inherit from a single parent
That is theory which perfectly solves the abstraction issue. Practice (or implementation) is a whole other story. In order to make implementation to work along with abstraction - the way I see it I can either
pollute the abstraction with ugly calls exposing the implementation (or giving hints about it) - killing the concept of abstraction, or
add casting from the abstraction to something that the implementation understands (dynamic_cast<>()).
add a global map pool of ISomething instances to UI specific elements (map<IElement*, QtElement*>()) which would be somewhat like casting, except done by myself.
All of these look ugly. I fail to see other alternatives here - is this where data abstraction concept actually fails? Is casting the only alternative here?
Edit
I have spent some time trying to come up with optimal solution and it seems that this is something that just can't be simply done with C++. Not without casting, and not with templates as they are.
The solution that I eventually came up with (after messing a lot with interfaces and how these are defined) looks as follows:
1. There needs to be a parametrized base interface that defines the calls
The base interface (let's call it TContainerBase for Containers and TElementBase for elements) specifies methods that are expected to be implemented by containers or elements. That part is simple.
The definition would need to look something along these lines:
template <typename Parent>
class TElementBase : public Parent {
virtual void DoSomething() = 0;
};
template <typename Parent>
class TContainerBase : public Parent {
virtual void AddElement(TElementBase<Parent>* element) = 0;
};
2. There needs to be a template that specifies inheritance.
That is where the first stage of separation (engine vs ui) comes. At this point it just wouldn't matter what type of backend is driving the rendering. And here's the interesting part: as I think about it, the only language successfully implementing this is Java. The template would have to look something along these lines:
General:
template<typename Engine>
class TContainer : public TContainerBase<Parent> {
void AddElement(TElementBase<Parent>* element) {
// ...
}
};
template<typename Engine>
class TElement : public TElementBase<Parent> {
void DoSomething() {
// ...
}
};
3. UI needs to be able to accept just TContainers or TElements
that is, it would have to ignore what these elements derive from. That's the second stage of separation; after all everything it cares about is the TElementBase and TContainerBase interfaces. In Java that has been solved with introduction of question mark. In my case, I could simply use in my UI:
TContainer<?> some_container;
TElement<?> some_element;
container.AddElement(&element);
There's no issues with virtual function calls in vtable, as they are exactly where the compiler would expect them to be. The only issue would be here ensuring that the template parameters are same in both cases. Assuming the backend is a single library - that would work just fine.
The three above steps would allow me to write my code disregarding backend entirely (and safely), while backends could implement just about anything there was a need for.
I tried this approach and it turns to be pretty sane. The only limitation was the compiler. Instantiating class and casting them back and forth here is counter-intuitive, but, unfortunately, necessary, mostly because with template inheritance you can't extract just the base class itself, that is, you can't say any of:
class IContainerBase {};
template <typename Parent>
class TContainerBase : public (IContainerBase : public Parent) {}
nor
class IContainerBase {};
template <typename Parent>
typedef class IContainerBase : public Parent TContainerBase;
(note that in all the above solutions it feels perfectly natural and sane just to rely on TElementBase and TContainerBase - and the generated code works perfectly fine if you cast TElementBase<Foo> to TElementBase<Bar> - so it's just language limitation).
Anyway, these final statements (typedef of class A inheriting from B and class X having base class A inheriting from B) are just rubbish in C++ (and would make the language harder than it already is), hence the only way out is to follow one of the supplied solutions, which I'm very grateful for.
Thank you for all help.
You're trying to use Object Orientation here. OO has a particular method of achieving generic code: by type erasure. The IWindow base class interface erases the exact type, which in your example would be a QtWindow. In C++ you can get back some erased type information via RTTI, i.e. dynamic_cast.
However, in C++ you can also use templates. Don't implement IWindow and QtWindow, but implement Window<Qt>. This allows you to state that Container<Foo> accepts a Window<Foo> for any possible Foo window library. The compiler will enforce this.
If I understand your question correctly, this is the kind of situation the Abstract Factory Pattern is intended to address.
The abstract factory pattern provides a way to encapsulate a group of individual factories that have a common theme without specifying their concrete classes. In normal usage, the client software creates a concrete implementation of the abstract factory and then uses the generic interface of the factory to create the concrete objects that are part of the theme. The client doesn't know (or care) which concrete objects it gets from each of these internal factories, since it uses only the generic interfaces of their products. This pattern separates the details of implementation of a set of objects from their general usage and relies on object composition, as object creation is implemented in methods exposed in the factory interface.
Creating a wrapper capable of abstracting libraries like Qt and Gtk doesn't seems a trivial tasks to me. But talking more generally about your design problem, maybe you could use templates to do the mapping between the abstract interface and a specific implementation. For example:
Abstract interface IWidget.h
template<typename BackendT>
class IWidget
{
public:
void doSomething()
{
backend.doSomething();
}
private:
BackendT backend;
};
Qt implementation QtWidget.h:
class QtWidget
{
public:
void doSomething()
{
// qt specifics here
cout << "qt widget" << endl;
}
};
Gtk implementation GtkWidget.h:
class GtkWidget
{
public:
void doSomething()
{
// gtk specifics here
cout << "gtk widget" << endl;
}
};
Qt backend QtBackend.h:
#include "QtWidget.h"
// include all the other gtk classes you implemented...
#include "IWidget.h"
typedef IWidget<QtWidget> Widget;
// map all the other classes...
Gtk backend GtkBackend.h:
#include "GtkWidget.h"
// include all the other gtk classes you implemented...
#include "IWidget.h"
typedef IWidget<GtkWidget> Widget;
// map all the other classes...
Application:
// Choose the backend here:
#include "QtBackend.h"
int main()
{
Widget* w = new Widget();
w->doSomething();
return 0;
}
I have had an idea for a non standard way to handle multiplatform interfaces in C++ and would like to know if that is generally a bad idea and why.
Currently I can only think of one disadvantage: It is very(?) uncommon do to something like that and maybe its not obvious how it works on first sight:
I have a class that will be used on different platforms, for example CMat4x4f32 (4x4 matrix class using 32 bit floats).
My platform independent interface looks like this:
class CMat4x4f32
{
public:
//Some methods
#include "Mat4x4f32.platform.inl"
};
Mat4x4f32.platform.inl looks like this:
public:
// Fills the matrix from a DirectX11 SSE matrix
void FromXMMatrix(const XMMatrix& _Matrix);
It just adds a platform depending interface to the matrix class.
The .cpp and the Mat4x4f32.platform.inl are located inside subfolders like "win32" or "posix" so in win32 I implement the FromXMMatrix function. My buildsystem adds these subfolders to the include path depending on the platform I build for.
I could even go a step beyond and implement a .platform.cpp that is located inside win32 and contains only the functions I add to the interface for that platform.
I personally think this is a good idea because it makes writing and using interfaces very easy and clean.
Especially in my Renderer library that heavily uses the Matrix class from my base library I can now use platform depending functions (FromXMMatrix) in the DirectX part as if I dont have any other platforms to worry about.
In the base library itself I can still write platform independent code using the common matrix interface.
I also have other classes where this is useful: For example an Error class that collects errors and automatically translates them into readable messages and provide some debugging options.
For win32 I can create error instances from bad DirectX and Win32 HResults and on Linux I can create them from returned errno's. In the base library I have a class that manages these errors using the common error interface.
It heavily reduces code required and prevents having ugly platform depending util classes.
So is this bad or good design and what are the alternatives?
It sounds like you're talking about using the bridge pattern:
http://c2.com/cgi/wiki?BridgePattern
In my personal experience I've developed a lot of platform independent interfaces, with specific implementations using this pattern and it has worked very well, I've often used it with the Pimpl idiom:
http://c2.com/cgi/wiki?PimplIdiom
As in alternatives I've found that this site in general is very good for explaining pros & cons of various patterns and paradigms:
http://c2.com/cgi/wiki
I would recommend you used "pimpl" instead:
class CMat4x4f32
{
public:
CMat4x4f32();
void Foo();
void Bar();
private:
std::unique_ptr<CMat4x4f32Impl> m_impl;
};
And then in build-file configs pull in platform specific .cpp files, where you for instance define your platform specific functions:
class CMat4x4f32::CMat4x4f32Impl
{
public:
void Foo() { /* Actual impl */ }
void Bar() { /* Actual impl */ }
// Fills the matrix from a DirectX11 SSE matrix
void FromXMMatrix(const XMMatrix& _Matrix);
};
CMat4x4f32::CMat4x4f32() : m_impl(new CMat4x4f32Impl()) {}
CMat4x4f32::Foo() { m_impl->Foo(); }
CMat4x4f32::Bar() { m_impl->Bar(); }
For a project, I am being asked to create a VST using the Steinberg SDK, i'm using version 2.4.
The issue that I'm having is error:
cannot allocate an object of abstract type 'mySynth'.
When attempting to compile, the error brings me to this section of code:
AudioEffect* createEffectInstance (audioMasterCallback audioMaster)
{
return new mySynth (audioMaster);
}
I'm a beginner to both c++ and VST programming, I've had no issues compiling the sample AGain and ADelay, as well as the vstxSynth. This is the first attempt of my own, and its really confusing me, from looking at the sample code i cannot seem to find any reason as to why this shouldn't work.
any help would be greatly appreciated. As this is a major learning curve for me, i would appreciate if you could apply with a simplest explanations as possible.
Thankyou :)
Without seeing the class mySynth code it is hard to say but this error is commonly encountered when you have a class containing a pure virtual function. Either that or you have derived from a base class with a pure virtual function and have failed to override it with a derived class implementation.
If you do not know what that means, look in your class (and sub classes) for functions declared like this
virtual int my_function() = 0;
This kind of function is a pure virtual function and a class that has one is considered an abstract class and cannot be instantiated. In order to do so you would need to provide an implementation.
Your processReplacing() method is not correctly overriding signature declared in the base class AudioEffect. The signature looks like this:
void processReplacing(float** inputs, float** outputs, VstInt32 sampleFrames);
Your override is using double, it should use float instead.
In many cases, I would like to override a Qt class to extend or modify its behavior. But almost all Qt classes uses an internal private class such as QNetworkDiskCachePrivate inside QNetworkDiskCache. I know there are advantages of this approach. But there is a HUGE problem of the private class: it makes overriding the class a lot more difficult. With other C++ class library with source code, I usually override a class method, copy the code from the implementation in the parent class and make small modifications here and there to achieve the behavior I want. However, in Qt, the private class is not exported and not visible to the derived class. Since Qt classes maintains the critical internal data in the private class through the "d" member, the invisibility of the private internal class makes the possibility of behavior extension very limited. You can only play with the few exposed public method.
I tried extracting the entire source files of the class and renaming the class name and file names. But the Qt class library is so much intertwined that extracting a single class out of it is messy as well in most cases.
Do I miss something here? Or Qt classes are just really bad in terms of extendability?
Qt classes are better than most in terms of extendability; they often have hooks to change their behavior without resorting to copying and pasting an entire method. Having said that, if the generally accepted methods of extending don't work, yes the Qt classes are harder to hack. That's probably a good thing because copying-pasting-and-modifying the base class implementation means that your derived class won't get any improvements or bugfixes that are made in the base class implementation.
If you want to do it, you're going to need to convince your build system to let you include the private headers and then refer to the private classes from your new implementation. Pay attention to the disclaimer in the Qt docs; when you do this you are opening yourself up to breakage with every new version of Qt that is released (Qt only guarantees the public API, and you're messing with its internals). Qt's public API is wonderfully readable and documented; the internal code can be pretty cryptic, so you really, really want to be sure that you can't accomplish what you want with the public API. If you're still resolved to use the private class stuff, this might help.
Your approach is wrong and bad! To extend a Qt, and more in general C++, code you don't have to copy the source code and modify it where you need. You should (have to) use extending OOP(Object Oriented Programming) paradigm. In C++ you should write something like:
#include <iostream>
using namespace std;
class A
{
public:
A(){x=1;}
void writeName(){cout << "my name is A";}
void writeNumber(){cout << "my number is " << x << endl;}
private:
int x;
};
class B : public A
{
public:
B(){}
void writeName(){cout << "my name is B and i'm better then A" << endl;}
};
int main()
{
B *b= new B();
b->writeName();
b->writeNumber();
return 0;
}
//output:
my name is B and i'm better then A
my number is 1
In this way B does all that base class A does and you add your methods(extend base class) to fit your needs. If you take a look at qt example code this is usually the approach used to do something not included into default qt widget behaviour. In example ItemDelegate customizations: you write your own class MyItemDelegate that extend QItemDelegate: link
Or Qt classes are just really bad in terms of extendability?
Qt is "only" a framework build up C++ language. This means that everything you can do in C++ you can do with Qt.