Global Moderators group

ferdinand

While my UI synchronization from the GeDialog to the Attribute Manager parameters and vice versa runs perfectly safe on the main thread (hope so :-)) , the crash was triggered inside MSG_DESCRIPTION_COMMAND when clicking the "Convert" button. In that moment, my code overwrites the temporary audio file, temporarily flushes the track path with an empty string "" to force C4D to clear its memory buffer, and reloads the track. Without protection it somehow collided with Redshift or MoGraph trying to read the document's audio properties during a redraw cycle, resulting in the access violation inside the audio driver callback (wdmaud.drv).

First of all: I am happy that you found your fix.

But this should not happen, and would imply a severe bug on our side. You should be able to write data as you desire on the MT. I am also not sure if the AI did not misinform you a bit. The stack trace which is found in a bug report contains raw function pointer offsets. Apart from some guesswork based on the DLL names, the offsets are meaningless for a human, even an AI cannot read this. To become meaningful, these stack traces must be resolved by our bug ticket system which then turns the function offset pointers into function and method names and their file and line numbers (it then looks more or less the same as the Python stack traces you know). You can only resolve this when you have access to the debug database /source code of Cinema 4D, which is for obvious reasons not shipped with Cinema 4D.

Did you submit your crash when Cinema 4D asked you to do so? Because I do not see it in our bug tracker when I search for that stack trace. The strack trace in your crash report must be read bottom to top, i.e., the highest item is the stack frame where it crashed.

CINEMA_4D_Crash_Report_WINDOWS
{
	Call_Stacks
	{
		Call_Stack_Thread_57060
		{
			VCRUNTIME140.dll:	_NLG_Return2 + 0x6c0 (SP: 0x0000006CAA3FED68, PC: 0x00007FFEB8DB0CF0) // Here is goes 'poof'
			c4d_base.xdl64:	0x00007FFD9CDB07E6 (SP: 0x0000006CAA3FED70, PC: 0x00007FFD9CDB07E6)
			c4d_base.xdl64:	0x00007FFD9CDAC864 (SP: 0x0000006CAA3FEDE0, PC: 0x00007FFD9CDAC864)
			c4d_base.xdl64:	0x00007FFD9CDAC503 (SP: 0x0000006CAA3FEE80, PC: 0x00007FFD9CDAC503)
			c4d_base.xdl64:	0x00007FFD9CDB480F (SP: 0x0000006CAA3FEF60, PC: 0x00007FFD9CDB480F)
			c4d_base.xdl64:	0x00007FFD9CDB5914 (SP: 0x0000006CAA3FF500, PC: 0x00007FFD9CDB5914)
			c4d_base.xdl64:	0x00007FFD9CDB755C (SP: 0x0000006CAA3FF550, PC: 0x00007FFD9CDB755C)
			c4d_base.xdl64:	0x00007FFD9DA833B4 (SP: 0x0000006CAA3FF590, PC: 0x00007FFD9DA833B4)
			c4d_base.xdl64:	0x00007FFD9DA82F45 (SP: 0x0000006CAA3FF5F0, PC: 0x00007FFD9DA82F45)
			winmmbase.dll:	DriverCallback + 0x5a (SP: 0x0000006CAA3FF630, PC: 0x00007FFEB126D38A)
			wdmaud.drv:	0x00007FFE1D202A35 (SP: 0x0000006CAA3FF670, PC: 0x00007FFE1D202A35)
			wdmaud.drv:	0x00007FFE1D2020F4 (SP: 0x0000006CAA3FF6E0, PC: 0x00007FFE1D2020F4)
			wdmaud.drv:	0x00007FFE1D201E45 (SP: 0x0000006CAA3FF970, PC: 0x00007FFE1D201E45)
			KERNEL32.DLL:	BaseThreadInitThunk + 0x17 (SP: 0x0000006CAA3FF9A0, PC: 0x00007FFED3BAE957)
			ntdll.dll:	RtlUserThreadStart + 0x2c (SP: 0x0000006CAA3FF9D0, PC: 0x00007FFED52A7C1C)
			Registers
			{
...

I.e., it crashed in VCRUNTIME140.dll, a Visual C++ Runtime component that is responsible for executing C code. This hints at low level operations such as memory allocation or hardware drivers. And you are right, wdmaud.drv is the Windows Media audio driver. c4d_base.xdl64 is then the base library of the Cinema API, there are a lot of things to be found in there and without resolving the report we cannot know where the problem lies (the stack frame in the Cinema API which then invokes something in VCRUNTIME140.dll). So, this basically goes "Audio Driver -> Cinema Core -> C dinosaur code -> poof".

Python plugin execution modules do not show up at all (which means that this happens quite a bit after any Python code ran). And Mograph and Redshift modules do not show up in the crashing thread (MG shows up one thread before but that does not mean much).

It would be great if you could submit the bug report, so that our crash handler can resolve it. I can also technically add your crash dump manually, but that is always a bit of a hassle. This is pretty much guaranteed to be a severe bug somewhere in the audio memory management.

Cheers,
Ferdinand

edit: I edited out the crash report download link in your posting, as it contains some minor sensitive details about your system we do not want to publish to the world when we do not have to

PS: And we will of course never shame users for their code, as that would be very counterproductive to what we are trying to do: help developers.

ferdinand

@ThomasB said in Thread safety when handling CTrack in TagData.Message() on button click:

I think you misunderstood me. I’m not trying to report a bug here, since the issue isn't with Cinema 4D itself.

No, I did not misunderstood your situation (at least I think so ). We sometimes ask people to report a formal bug report so that we can reproduce an issue. This is not necessarily bound to the bug being in Cinema 4D. Although we often do this when we suspect that the bug is on the Cinema side or at least in a grey area where the plugin does something that is not so great but Cinema also drops the ball in some shape or form.

Your code, at least the one you shared with us, does not do anything wrong. And even though I know you have put a lot of work in your reply here, a lot of text and diagrams do not help in concretely fixing the issue. To answer a few questions anyway:

NodeData::Message usually runs on the main thread (and you additionally check), so we are fine.
Dialog code also usually runs on the main thread. The only exception can be drawing code (something like GeUseraArea::DrawMsg), although drawing code usually also runs in a special section of the main thread. Hence my hint to use GeIsMainThreadAndNoDrawThread instead of GeIsMainThread in my first posting.
Generally there is no guarantee that any code runs on the MT. As an example, NodeData::Message calls are usually on the MT, especially the message MSG_DESCRIPTION_COMMAND. I.e., when a user clicked a button in your node this should run on the MT as you often want to do GUI things or modify the scene. And Cinema will (should) honor this. But nothing prevents me, Evil Bob the developer, from grabbing your tag, creating a new thread then calling yourTag.Message(MSG_DESCRIPTION_COMMAND, BaseContainer()) from this new thread and with that violate the assumption that description commands alwary run on the MT.
Core messages are also usually sent from the MT, both in a dialog and in a MessageData; so CoreMessage functions should usually run on the MT. Core message (i.e., event) evaluation is also decoupled. When you set a (core) event from a non-MT thread (via SpecialEventAdd), Cinema should properly synchronize and execute the event on the MT. But there could be of course bugs in our code. You should therefore always shield your code with GeIsMainThreadAndNoDrawThread or GeIsMainThread if your code could also run in a drawing context.

It is good that you have an eye on the threading safety in Cinema as this is something that often trips developers. But I do not think that threading is here the issue. Threading violations usually lead to crashes, corrupted data, or inexplicable behavior. Slowdowns usually mean that either code runs way more often that you think, e.g. some feedback loop between your tag and dialog, or that there is some resource fighting going on. Playing audio means that hardware resources must be allocated. When they are constantly dropped and reallocated, because something else wants to access them too, this can lead to slowdowns. This is still just a guess into the blue of mine, but it would fit the symptoms you are describing.

Could you please:

Confirm that the issue also happens for your with the simplified plugin.
Provide a step by step bug report to reproducing the issue as described here.
Check that the issue does not happen when you delete your tag (but leave the sound track in the scene). I really want to rule out that Cinema does not have a problem with audio playback on some hardware in general.

When push comes to shove, you can also share your full plugin in private with us via sdk_support(at)maxon(dot)com. When you can reproduce the issue with the simplified plugin, this is of course sufficient for us to investigate the issue. But if you cannot reproduce the issue with the simplified plugin, then we would need to see the full plugin to understand what is going on.

Cheers,
Ferdinand

edit: I now also tried on my Win 11 machine (Intel chipset, a bit beefier GPU). And I cannot detect any slowdowns in normal scene playback or when using the RS render view. However, when I use the Calculate Fps tool (just press SHIFT + C and type 'FPS'), I experience distorted audio and the view port becomes sightly laggy. This happens with and without your tag, an audio track alone seem to be enough.

ferdinand

Hello,

This is a bug. I have fieled it under 'ITEM#649699 Timeline does not react to NBIT selection changes on tracks anymore'. It is unfortunately not a bug in the Python or core C++ API which I could just fix myself, but either a bug in the scene evaluation or the timeline. So, we will have to wait until the owning team tackles it. I notified the owners that timeline automation is a popular scripting task and that they therefore should fix this.

For now, the only thing I can recommend is to use 2026.2 when you want to carry out such tasks.

Cheers,
Ferdinand

ferdinand

Hello @chuanzhen,

Thank you for reporting this. At first glance this looks like a bug/regression in 2026.3.0. I'll have to check in more detail myself before I can say for sure. But your code is also incorrect, the NBIT_TLX_SELECT2 bits are internal and not for what you think they are. You must use NBIT_TLX_SELECT instead. But they are currently malfunctioning for me on Windows in 2026.3.

Until I am sure, I will not yet classify this as a bug.

Cheers,
Ferdinand

In 2026.2.0, this code randomly selects and deselects tracks in an all timelines for the active object. I.e., you can spam-click the script and see the track selections 'jump around'. In 2026.3 it does exactly nothing (at least on my Windows machine).

import c4d
import random

def main() -> None:
    for track in op.GetCTracks():
        bit: int = random.choice([c4d.NBITCONTROL_SET, c4d.NBITCONTROL_CLEAR])
        for tl in (c4d.NBIT_TL1_SELECT, c4d.NBIT_TL2_SELECT, c4d.NBIT_TL3_SELECT, c4d.NBIT_TL4_SELECT):
            track.ChangeNBit(tl, bit)
    
    c4d.EventAdd()


if __name__ == '__main__':
    main()

ferdinand

Hey,

Can you provide a bit more context? I tried your plugin on Cinema 4D 2025.2.1 and macOS 26.5.1. I added your tag to a scene, clicked the "Add Audio" button, and started playback.

I experience no slowdowns when I run the scene playback (F8) or the RS render view.
I hear the base_1.wav sound playing your plugin adds.

Can you please:

Provide the type and version of operating system you use.
Provide the version of Cinema 4D you use.
Describe the hardware you use.
Provide an example scene.
Check if you experience the same slowdowns when your plugin is being removed from the scene (but the sound track it has added is being left in.
If necessary, provide a step-by-step instruction to describe your bug. See here for how to formally make a bug report.

My hunch right now is that your plugin has probably little to do with the slowdowns, but that sound track playback is the culprit which might lead to 'resource fighting' on some systems.

Cheers,
Ferdinand

ferdinand

It did, thanks, I will have a look.

ferdinand

@ThomasB

Absolutely, but you have to either grant me access or make the whole folder public.

ferdinand

Dear community,

GeDialog::GetFilename is broken in 2026.3.0 in both the C++ and Python API, returning the empty filename/string, even when a gadget holds a valid string. Plugins using dialogs which use Filename parameters are therefore currently malfunctioning when used in 2026.3.0. The issue does not exist in 2026.2.0 or earlier versions.

We will deploy the hotfix for this issue in the coming weeks.

Cheers,
Ferdinand

ferdinand

Hello @ThomasB,

could you share your plugin via something like dropbox or google drive with us? You upload above seems to have failed.

Your code looks fine, you do everything correctly at first glance. You only try to modify the scene in the context of MSG_DESCRIPTION_COMMAND (which should only be invoked from the main thread) and shield yourself against rogue actors by also checking c4d.threading.GeIsMainThread() (slightly better would be GeIsMainThreadAndNoDrawThread but that is just semantics). Your node does also not do anything wildly expensive in its Init/__init__.

But I am sure you are not just imagining your performance issues. Generally speaking, your code should only run when the user clicks the button with the ID PY_ADD_AUDIO in the description of your tag. So, this should not be able to accidently run when you render or while scene playback (which I assume is what you mean with 'running (an) animation').

PY_TRACK seems to be a parameter of type DTYPE_BASELINK where you just link the newly created track. I cannot really see anything going wrong with this, as this is very harmless. I also checked if there is any 'special sauce' in creating sound tracks, as they are one of the special tracks, but as far as I can see, we are doing this internally exactly like you do it. So, this also does not seem to be a case of an incorrectly allocated node, which then constantly causes internal errors.

Cheers,
Ferdinand

ferdinand

Hey @ECHekman,

well, when a node displays an embedded description (what you exemplify at the case of a BaseLink), it uses a DescriptionCustomGui too. Other parameter types aside from a BaseLink which can do this are for example field lists.

I am quite frankly a bit surprised that this even bubbles up in the form you report it, that you get a DescID which is selected inside a DescriptionCustomGui that is shown by the node in the DescriptionCustomGui you opened yourself. Attribute Manger selection states (and by extension DescriptionCustomGui) are not a public API feature, as we usually keep our GUIs sealed, i.e., inaccessible to third parties. DescriptionCustomGui is here a bit in a grey area, but I am afraid there is no way to do what you want to do. To do what you want to do, you would need access to internal systems.

And other than in some other cases, where we do not always had the time to expose something (and are open to the idea of changing something), this is for GUIs not the case; they are intentionally sealed as we do not want third parties to change basic UX concepts.

My general advice would also be to not to try to overcome this boundary (that a plugin reacts to which parameter in a node is being highlighted by the user), as you break UX conventions of Cinema 4D with that.

Cheers,
Ferdinand

You can do this, but it is very hacky:

Get the description of the node(s) you are currently displaying in the your DescriptionCustomGui.
Check if desc is a member via CheckDescID (I think GetParameter would also work and return an empty container when the ID does not exist).
When the ID does not exist, start browsing the container for parameters that are of a DTYPE that implies an underlying node, such as DTYPE_BASELINK.
When you find such parameter, get the node node, and check there.
Rinse and repeat recursively.

Issues:

You cannot distinguish the case where an object A has two BaseLink parameters which both hold an object of type T, but not the same instances.
You will run into issues with DescID translations which some nodes might do. This is a really big point, which is probably already overlooked in your current code.
Nested node relations can get REALLY complicated. BaseLink is trivial, but stuff like field lists, volume lists, or some special shader stuff can get really complicated. You would probably only have to worry about base links and field lists in your case, as other renderers are irrelevant for you, but field list alone are already complex enough that I would strongly advise against 'just implementing it'.

I	i_mazlov
J	jana
M	maxon
F	ferdinand
M	m_adam

Global Moderators

Posts

Member List