dast

I had used Reaper a while, some years ago, for editing voice-over takes and effects, but never really managed to stick to it for music making. As far as I remember I seemed to have had issues with Kontakt and other virtual instruments, and was too impatient to get used to its workflow. Went for Tracktion instead. As for the plugins I am developing, most except the latest one are listed in a blog here at the Cafe, as well as having their own threads in the plugin section of the forum. Right ... the Atari STE. Could indeed have as much as 4MB if I remember correctly. Never could justify the "upgrade" from my STFM, which I purchased having 512KB and had it upgraded to 1024KB. A few years later purchased a PC 80486 with ... 16MB. Still far away from the 16GB which are common now. Still, I much more enjoyed the Atari than any PC I have had in all these years. Shame for the lousy graphic resolution, back then.

I remember the 512KB and 1MB versions, (STFM versions), but cannot recall the 2MB. Was that the STE, the TT, ...?

I agree. Have purchased Cubase Elements 8 a few years ago. Never really used it to its full potential, as starting the application seemed to take forever. Each time I wanted to do a quick session, the amount of time to wait loading the application just killed the inspiration. Have since tried Reaper, and am now focused on Waveform (formerly know as Tracktion). Both of them launch in a blink of an eye. But, unfortunately, other things are keeping me away from music making ... and even from doing 3D. A decade ago it used to be building and flying model airplanes, but since a few years my attention is now fully turned to plugin development.

Have been an ST(FM) user as well, but more for the graphics than for midi ... especially STOS. To be honest, prices have come down and storage has increased, both exponentially. But what about the fun and excitement? Maybe it's nostalgia, or old age, but the 80s-90s seemed to be more exciting computer-wise (as a teen) than today (as an old fart), even if things were barely affordable then ... And the music was better.

Both you and @RobertL should have received the updated version. I have added some documentation regarding the script, and even added a script example. Looking forward to both your feedback, before providing the update to other customers. As for Seamilar, PolyGnome (as well as Dials), they're currently still 15% off, and EasyUV is at 40% discount ... for the whole month of February.

Yes, every output port requires it's variable to be defined as global. I was a little too fast with my response for the second script, and I omitted the 'global', as well as forgetting the namespace 'c4d' in front of the rotation attribute. As such, the working script should be # construct a matrix from Position and Rotation, # input ports are Position and Rotation, output port is NewMatrix import c4d def main(): global NewMatrix NewMatrix = c4d.utils.HPBToMatrix(Rotation, order=c4d.ROTATIONORDER_DEFAULT) NewMatrix.off = Position As you figured out by now, I hadn't tested the script before submitting ;-)

As mentioned, name your input and output ports accordingly. These port names are used in the scripts. If these don't match you'll get the error you describe.

OK, got it. As I thought, the input ports are "Position" and "Rotation", both of type vector, while the output port is "NewMatrix" of type matrix. So, when replacing the COFFEE node with a Python Node you should create the appropriate input and output ports. With the first scripts the input and output ports are floating point values. By default, when you create a Python node in Xpresso you get 2 input ports ... of type Real (or floating point), and an output port, again of type Real. What you need to do for the second script is create a Python node, remove the input and output ports, and create new ones of the appropriate types. I don't think you can change the port type (at least you could not in the past), therefore you need to remove the existing ports and create new ones. Name them accordingly and you'll be set!

You could google this and find a better answer, but I'll try my best at explaining it. The "->" you see in COFFEE and other programming languages (C++), is a way to access an object's member or function. In the second script there is this "InMatrix" variable which refers to a matrix object, an instance of a matrix class. Be careful with "object". In this context it isn't a Cinema 4D mesh object or null object, nor deformer, nor generator, ... The object here is a "container" which holds some data and functions (members and methods in C++). The matrix class has a GetClone function which allows to create a copy of itself and pass it along. InMatrix->GetClone() thus means that from our InMatrix object, we call its internal function called GetClone, and the resulting copy is assigned to NewMatrix, a new object instantiated from the matrix class. EDIT: Well, for completeness. In C++ (other languages probably as well, but I am most familiar with C++) to access members and methods of an instantiated class or structure one can use "->" or sometimes just a dot. myObject->member myObject->method() - or - myOtherObject.member myOtherObject.method() It all depends how the object was instantiated, as a pointer or not. But I guess this all is getting beyond the scope of this forum.

I can't seem to find the second COFFEE node you are referring to. All I see are 7 COFFEE nodes with the first script.

Here is the first # Get the "shortest" angle between two vectors, provided via input ports Input1 and Input2, # The result is sent to output port Output1 import c4d def main(): global Output1 Output1 = c4d.utils.GetOptimalAngle(Input1, Input2, c4d.ROTATIONORDER_DEFAULT) And the second one As far as I can see this script is meant to create a matrix from a rotation and position, provided via input ports called Rotation and Position. The output port is then NewMatrix. I am not 100% sure this is what it is supposed to be, but without the actual scene file where the Xpresso and nodes can be investigated from, it is hard to tell. So, I'll go with my first assumption. The code for this is then # construct a matrix from Position and Rotation, # input ports are Position and Rotation, output prt is NewMatrix import c4d def main(): NewMatrix = c4d.utils.HPBToMatrix(Rotation, order=ROTATIONORDER_DEFAULT) NewMatrix.off = Position

I will contact you when I get a release version ready. And will provide you with a link from a gmail account ... no blocking out anymore.

It's Sunday morning, 6 AM. I just woke up with a possible solution to your request. I still need to see if I can get this solution implemented. But I guess I will have to get rid of the sticky key code as it kind of interferes with this new multi toolset shortcut solution. Since the sticky key didn't behave as expected on every version of Cinema 4D or OS platform, I was already more or less inclined to remove this anyway. Will report back when I have more news ... Edit: OK, the concept does work, but I had some trouble with the assignment of the different shortcuts. Basically what needs to be done is for the user to create a script per wanted toolset shortcut. Then assign a shortcut to each of these scripts ... and that's where Cinema didn't cooperate. It would allow me to assign a shortcut only to the last script of the set I had created. But restarting Cinema 4D after having created all the scripts does seem to do the trick. The script is simply passing the toolset number to Dials, so all scripts are equal except for the toolset number # Dials - toolset shortcut helper # 'TOOLSET' refers to the toolset number you would want to activate # Any number between 1 and N, where N is the total number of toolsets available. # Using toolset number 0 will activate the last used one. # When a toolset number is provided out of range the plugin will revert to using 0 # # Assign a shortcut to this script to activate the required Dials toolset # (for this to work you'll need Dials v1.2) import c4d TOOLSET = 1 if __name__=='__main__': c4d.CallCommand(1041321, TOOLSET) The above script uses TOOLSET = 1 to activate the first toolset, simply create different of these scripts, replacing the '1' with the required toolset number. @RobertLLet my know if you want to test this new version.

Short answer: you can't. Cinema 4D is designed (as far as I know) to use a single shortcut for a single plugin. Before implementing the current toolsets via the middle ring, I researched possible solutions to provide multiple dials. One solution was to provide a command plugin per dial, which would allow users to define separate keyboard shortcuts per dial. This would also mean that the number of dials was predefined, as each dial would require a unique plugin ID obtained from MAXON. Furthermore, this would mean that the number of dials (thus toolsets) could not be created dynamically At that point, I assumed people would prefer having a single plugin, instead of one entry per dial, and be able to dynamically create the number of dials they wanted. As mentioned above, for each dial a separate plugin ID is required. I could provide 5, 10, 20 entries. Then someone comes along and requests 21 ;-) I would thus much more prefer a dynamic solution ... which I currently do not have. Let me sleep over it for a few nights, and I might come up with something. Nothing promised.

The free version of the plugin, available to download here at the C4DCafe, is not a demo version but has limited features. The fading in of the icons one by one is a limitation of this free 1.0 version. When you purchase the paid version (updated to 1.1), next to support you also obtain additional features such as the possibility to create multiple dials, as well as favorites per tool. This version does not have the limitation of fading in icons one by one. Features of the paid version are available in the demonstration video I provided a few posts back (https://www.c4dcafe.com/ipb/forums/topic/103440-dials-was-wheel-of-tools/?do=findComment&comment=687595)

A quick demonstration video has been added to the first post. It shows most of the available tools in action, hoping it provides an idea of the features available. I don't have demo versions of my plugins, except for Dials. While I understand people would like to try out to see if a plugin does fit one's workflow, it isn't always manageable to make a demo version without crippling the plugin. EDIT: since plugin is available free of charge, no need for a demo version anymore

I am planning to create some videos to demonstrate the available features of this plugin. Intended for beginners, as this is whom this plugin was focused for. However, since EasyUV is heavily based on Seamilar, the basic UV editing (move/rotate/scale) of points, edges, polygons and island is similar. You could thus check out the video created for Seamilar to get an idea how these tools are used. The original move, rotate and scale philosophy from the native core UV tools was kept. As such, these 3 operations use 3 different tools, each with their icon and Attribute Manager settings. In a future update I intend to merge these 3 tools into a single tool, as I myself have encountered scenarios where it would optimize the workflow in a great way having this single transform tool instead of the current separate actions. As said, this is future, so this should not be taken into account for your current decision making to use this plugin or not. As for the EasyUV tag versus the regular UVW tag: note that the EasyUV tag only stores the information related to seams and UV islands, the actual UV editing does happen on the regular UVW tag.

All I really needed was a way to render each separate icon with the same render settings, to the same folder, but with different filenames. In the end I only figured out a solution by creating a Take for each icon, manually naming the Take by the icon name it represents, and then using the Take name in the render settings. But then I figured I could step it up a little, as some icons were created using a perspective camera, while others with a simple top-down camera. With the Takes system, I could easily specify which camera to use. In the "old" days, I would have manually selected the appropriate camera, select the appropriate objects, hide the not-needed objects, change the output name in the render settings ... and press render. Rinse and repeat for all icons. It was a quick set up with Takes, but I need to use it more often in order to create some "muscle memory", as I already have forgotten how to do it. OK ... back on topic now.

EasyUV is ready and finalized. Available for Cinema 4D R16 upto R20, Windows and macOS. Available at Tools & Pixels For a limited period of time: introductory price of 15 euros.

Yes, the Python itself isn't the issue here. So the actual Python code could be shared to version before R17 ... when you copy/paste the entire code. Files containing Python code seem to be problematic when loaded into older versions. Although I haven't checked if Python scripts created in R17+ do have the same issue as the Python nodes in Xpresso or the Python tag. The hex editor was just a way to visualize the text data. Newline and carriage returns (ASCII characters 10 and 13, or 0a and 0d in hex) aren't visible in a regular text editor.

I understand you might think so, but NO, definitely not. From the start I assumed it was something related to how R16 did read or interpret the Python text data, triggered by the fact that you resolved the issue by retyping the first line of code. I went a little further, and just randomly added an empty line or a comment line anywhere in the Python code. This also - surprisingly - fixed the issue. I mean "surprisingly" in the sense that it is not code related. Went even further and saved the working version in R16 and compared both original and resaved text data (using Winmerge utility). This mentioned that both files used different carriage returns ... so I looked at both data in an hex viewer. This shows all characters in the text data, even the non-readable ones. Apparently, the R16 Python editor does use a different carriage return than R20. I assume that the switch between carriage return types was done at time of R17, since I can load the R20 Python in R19, R18 and R17 without issues. It's only R16 (and probably earlier versions) that show this problem. Anyway, there's not really something you can do about all this ... unfortunately. The only thing the user with an older version needs to do, is to force the Python editor to modify the carriage return by slightly modifying the content.

Not at all. What I noticed: when you import the more complex file into R16 and select the Python node, you can see C4D has trouble interpreting the Python content correctly. The Attribute Manager shows the Python code, but the second line - a comment line - is not correctly color coded. If you then open the Python Editor it does show correct color coding for that second line. By the way, I tested on R16.050 not sure what has been fixed since the version you have running, being R16.011 Checked the MAXON website, but they seem to only go back to R17 for available updates, so cannot really see if any Python interpreter or editor related fixes had been introduced between our two versions of R16. All I know is that this particular issue doesn't seem to be related to PEBKAC Wondering if the issue would be fixed without retyping the first line. Import the scene file, open Python Editor, press compile ... and check if the yellow title bar disappears. Just wondering.

I created a simple scene only containing a null, added an xpresso tag and in Xpresso created a python node. Left all default, saved the scene file and opened it in R19, R18, R17, R16. All version opened the file without problems. So, I can't really confirm the problem. From your first screenshot (with the error) it seems the first line looks like "import c4d, math". Shouldn't that read "import c4d.math", with a dot instead of comma? Is it maybe a locale thing istead, where decimal point in text is interpreted differently on different OS versions? Just thinking out loud.

I have been using Substance Painter for a while now. Purchased version 1 when it came out, and upgraded over the years. And while we don't actually know what the future will bring, I honestly don't have a good feeling about this merge with Adobe. I am still using an old perpetual license of Photoshop CS5.1, and wouldn't mind staying behind with Substance Painter 2.x if they ever intend to go subscription only. But as said, no idea how things will evolve ...

With all my other plugins converted to R20, and temporarily out of the way before I start adding new features, I wanted to spent some time on finalizing EasyUV. As a first step I wanted to get the plugin working for R16-R19. Step 2 would be to port it to macOS. And final two steps would be to port it to R20 on Windows, then to R20 on macOS. Quite some work ahead. For Seamilar I had created all icons in a drawing application. But this time around I wanted to model them, as I figured it would be faster to adjust. As well as reuse and interchange parts between icons. And it allowed my to finally learn how to use the Takes system inside Cinema 4D. As each icon is a different Take I could "simply" set up all the Takes and then perform a single "Render Takes". And all would be output as 32x32 bitmaps at the press of a single button, for perspective or top-view cameras. The scattering of the icons is maybe not that artistic, but I found it nice looking ... and it helped to take my mind of from all the coding I had been doing all day long. With step 1 completed it's time to take the next one.