I really like shell stuff because piping everything into a glorious web of functionality is great.

This is not easily done with graphical "IDEs" of any kind, including multimedia editors, which are a sore spot, in my opinion, in the Linux world.

You get really good folk doing some really good work in some tied together suite, and these good folk must then weep and sob because the rest of the suite has some awful, awful, awful aspect and people are giving the good developers grief. However, the developers are spread thin and often simply can not plug all the leaks in the ship.

This saddens me, because I tend to get really angry at awful GUI stuff because I'm a control freak (as in, I want good controls, not to control others (yes, despite my crusade against some specific text editor flavors)).
I could spend time becoming a better person on that front, but I'm gonna die in a few decades anyway and then people can dance around my grave and be merry, no, that would be a waste of time if I could just write code instead.

There are things like DBUS and OLE and whatnot, but I am very ignorant about them and their limitations, and, blind as I am, I would just sink into a mire of research. I am not a very good programmer, much less of a designer and I'm not even all that smart overall.

But I am of the rather strong opinion that IDEs must be smashed in favor of completely replaceable components, like virtual instruments in a DAW.

And since I mentioned Graphics, there's a rather thicc boy in the room, image/video/mesh/texture data.

Is there something that can already deal with such things, like unix sockets or something. Again, I am begging for spoonfeeding here. Not implementations, just answers on concepts. If you are learned in it, it's better to ask you for your input than have ignoramus me rustle through stuff and lose motivation cause I'm a scrub. I need direction.

Big data sharing is required so things like "one window (or applet/component)" is a "create asset component", this could be the user drawing something with brushes.
This component is completely self contained for its own purpose, but the data it creates should be usable by a "low latency viewer" for example (in the case of animation or video editing).

Things like OpenGL or Vulcan should be able to run off this shared memory. I have looked into This boost implementation but the "cannot hold C++ objects" bit confused me.
(Again, I'm not that good, I'm not that learned, I will write code but I don't have good knowledge for design. I don't wanna say code monkey, but..think code monkey )

So yeah, any input is welcome. How to share chunky chunks of memory between ravioli applications like in a DAW? Has it been done? What could I use?
(No need to explain mutexes (mutices?) and co to me, but if they need to be used in some special way, then that would be helpful. I know what they do, just not always where they should go. (I know that makes little sense after saying that i know what they do...but...alas :P ))

Edit:
And just to repeat it...it's gotta be a fast solution, fast enough for multimedia that is synced time wise.

P.S.:
The solution could be a 'no brainer' like literal shared memory, my issue is more about lack of knowledge about performance, etc.

Shmem and mutexes.

When you think about it, every other method copies, thus wasting time.

Images, videos, meshes and that stuff?

You just write to disk, load them from disk, and use disk files as the data interchange format. Have each application know the file paths.

Yes I'm serious.

If you have knobs to say, control where the camera in the viewport is (Is this a good example of what you want to get working?), then you store those parameters in only the viewer and use them only to control the camera in the viewer. You do not rerender all the stored images or write out new geometry data each time you move the camera.

You should look into using a game engine like Unreal for this.

It says "cannot hold any C++ object", but it can hold the subset of objects that avoid depending on process-specific addresses.

@rtmistler
shmem does seem to be the most suitable thing, so far, thanks. I'm just not sure if there's any size considerations, I mean, there shouldn't be, if it acts like, well, just a shared memory address thing.
But perhaps there are things like...that shared part playing alongside the non shared parts. Is that anything to worry about too much? Not even sure what I'm asking, but it's along the line of swapping and cache and such things.
Maybe these things are not to be worried about and the kernel does it on its own. I don't know.

@dugan
I want as few third party things as possible for the core of it all, everything executable being natively compiled would be best, no python or perl or anything else that have their own crazy dependency trees.

What I want to do is not redraw/render/recreate everything each frame, I just want to avoid duplication of memory.
In current IDEs (let's put multimedia editors in there too), these things are usually explicitly designed to be a collection of tools that work together according to some spec/vision and that's that.
I don't want this anymore. I want users to integrate their own things. It would act like an IDE, as in, the user 'defines' an IDE, which is like a container and into that container they wire components together that all share some sort of protocol as well as memory etc, like a 'premade' IDE.

Think of the assets as living in some shared memory place, on their own, it's where they always go during realtime interaction.
The user can then choose their favorite tool that works with these assets.

Animation software for example, there are usually two timeline flavors. Exposure sheet, and, well, timeline.
Both basically are the same thing, they are a list of cells, to which images and keyframe attributes are bound.

So if a user prefers the XSheet approach (classic animators and it's pretty popular in the Japanese animation sector, too) they plug in an xsheet, not a timeline.
Timeline preferring users do the opposite.

And on top of that, there could be any flavor of xsheet or timeline. Just like there are many flavors of terminal emulators or music players.

Want to do lip/sound syncing? audacity (for arguments sake) has now bindings for this format and can be integrated into the IDE and wires up with other controls and the transport and all that via a MIDI like protocol (MIDI is great, maybe it even works already, but maybe it needs to be expanded for modern multimedia needs, not just audio) or what ever DAWs use for their virtual instruments.

Terminal applications can be wired together like that no problem, but media works are mostly graphical, and I think a "unixy" approach to these 'customizable' IDEs would be quite beneficial for the wild west of Linux/*nix/free software.

Maybe one artist doesn't want "super viewer with color analysis overlays and whatnot" they want "sucklessTV" that just shows images, no bells and whistles.
(But both would take what they display from that shared memory storage )

Things like that. It would possibly decrease heartache that happens when passionate developers who are spread thin over a big suite (but actually only work on a subset of it) have to deal with a decrease in usage of the 'IDE' because something else of it sucks.

With the "do it yourself, now GUIs have not only 'pipes' but also no memory duplication and they work like if it had been designed to be a single unit" IDEs, this should not happen as much.

Edit:
These components would all be 'independent' on their own and wouldn't need to be bound together by an "IDE like container" but they could be, like MIDI devices, be virtually connected too. Like an Xsheet only controlling an audio player, no video player. Or the xsheet could open the garage door at the end of the animation, etc.
Basically, what we have for the terminal, only for GUI stuff.

A customizable IDE that behaves as if it had been designed this way, every time. Memory does not get needly duplicated because the designers of a, well, designed IDE would not do that, they know the components and what they do.
(In the case of multimedia, they know what the 'paintbrush part' does, and where it puts its data, and the 'render the things' part then displays that.

The customizable one should do this, too, but it will need some sort of ...protocol or interface or something. Like MIDI.

@ntubski
Thanks. I think I get it now (but can I explain it back to prove it? )
As long as the objects that are in that shared space only have dependencies that fall into the shared space, it will be all good?

One more example.

A camera can be keyframed to go left and right.
In a predesigned solution, maybe there is a widget for that, and it's knobs.

But what if a user prefers sliders?
As long as there is something (again, like MIDI, or DBus which can do such things) that tells the camera what to do, it doesn't matter what generates that data.

So "camerapanel" could be virtually anything.

I'm just using "Like an IDE" because Terminal stuff has scripts, a collection of tools wired up to do some task.
This GUI solution needs a container like that, too. Cause...who'd want to painstakingly rearrage bits every time they need some other task done?

It's just that simple messages like control codes are not enough. It's one thing to play a note on some device like with MIDI, but another to generate big media files in one thing and then have it used by some other.
I'm really mostly concerned about that.
It should have drop in replacement for media things, that follow some sort of schema.
Basically a marriage between a message/event system, and a media memory system that connects media usage, making it available for anything that is interested in a particular format/thing.

Edit:
Oh, and I'm only explaining right now. This is not like "make this for me"... I want to try it myself, at least the starts for it.
Probably nightmare mode, too...memory shenanigans are so tricky.

I think you just spent two posts describing Blender.

No, too much baggage. I'm thinking about...perhaps a 'new' GUI paradigm all around.

Never again have anything connected by force, for this stifles the...open source (term used for rhyming purposes).

Every future GUI application should behave like a CLI application in the ability to be chained together.
No more married by force setups. Every single GUI thing is a unix like specialist.

If there's a lot of overhead underneath that (underhead I guess) so be it. Many abominations already exist, but this one would at least unchain developers from baggage they have no interest in.

Security risks? Probably extremely difficult, I am not too sure but I would say it's a problem worth tackling.
GUIs should never be glued together by force beyond logical stuff like tabs and pull down lists.

An IDEs text editor should never be 'bolted in' again. Instead, there should be a sort of protocol that allows discovery of actions/attributes/whatever some GUI element or program wants from something else, and implement it if wanted.

Want super barebones stuff? No flashy blinkenlights in the editor? Pull out the IDEs custom editor and put in yours. Any event/message like "light up for breakpoint at this line number" not implemented gets negotiated away.

Don't like the icon pixel editor of your IDE? Kick it out, pull your image editor of choice in, as long as both use the required data/image structure and formats, who cares what you use to paint it.

Don't like the audio track editor of some video editor? Pull it out, push audacity in.
Apply an effect to the sample in shared memory via the video editing software? It changes in audacity.
Apply an effect in audacity to the sample? It changes in the video editor, because it's the same thing (but protected so only one thing can write to it at a time)

Don't like the audio level visualizer of your DAW? Pull it out, pull in something else. Maybe some visualizer nerd out there has the perfect solution but doesn't want to work on lets say Ardour as a whole.

Break the chains of the GUI world. No more force marriages.

It...must be possible somehow. I am too inexperienced to really wrap my head around even designing this (but I'm not alone on that, many global standards have committes and all that, do they not? )
But I'm going to at least try something, even if it's just some hackneyed, security nightmare hackjob prototype.

I feel you may, and may not be over-thinking things.

My humble opinion is that if this matters this much to you, then get involved with understanding how memory is addressed at the kernel level. As a result, you may derive optimizations where you'll have to write a memory manager shim for your software to use which is specialized versus the default way things are done now. If you use a shared memory segment, mutexes only give you a conveyance anyways and management of that segment is up to your code.

I'd suggest start with just using a shared segment and see how performance is. In parallel get versed in how segment sizes are derived, this may be universal, but likely it is per machine, and then see if you can architect to use that known size of a segment. But please do note that one can have a very efficient communications method but still have performance problems in their code. And for what it's worth, I feel based on what you're saying, you'll need a custom memory manager as part of your design.

The potential over-thinking part is that sometimes I find people to be unreasonable and they expect that they can attain clock speed response from hardware, but when they're using a general purpose OS to interface with that hardware. If that's an absolute mandate, then remove the OS, get true DMA hardware or dual port RAM, and write a purely custom embedded OS and also for a custom system which contains the acceleration components that benefit you the most.

I've spent an awful lot of time looking for and working to resolve performance bottlenecks. This is typical with custom designs and the details known there are exactly the predicted capabilities which should be able to be achieved. As a result, when performance problems are identified, they also are run fully to ground because we need to verify either that our design premises were correct/incorrect, or determine why code is not achieving what the design derivations predicted. These types of issues are fairly hard to do using the general purpose OS, but they're not impossible, just that you end up learning and being involved with the specific design of that OS in greater detail. In this case, the Linux kernel.

1 members found this post helpful.

The DAWs that I'm familiar with use a plugin architecture. The application/DAW manages the raw audio file disk storage and controls the access of the plugins through some form of processing buffers. I don't believe the model lends itself to a pipeline architecture because of the demands of real-time processing.

If real-time is not a consideration then a GUI can simply be process management for file operations, as already mentioned.

I do a certain amount of image processing in my current job. Much of it doesn't lend itself to real-time operations - I guess it depends on what sort of processing you're doing.

Geist, it doesn't sound like you're talking about more than one application. It sounds like you're looking to create one application where you can set up custom panels (as you can in most high-end animation programs, including Maya and Nuke). You don't need any form of IPC for that.

A google for "implementing plugin architecture c++" (no quotes) got me lots of relevant hits.