patch crashes after saving patch in directory with non-latin filename.

[H-MLim]

hi. this issue came again. but not only for vanilla patch this time. when right after I saved the patch on plug, the patch crashes when I try to make an object, and type any. (build 35e0ec2 / Win11)

[dromer]

Does this happen with any patch? (even an empty one?)

[H-MLim]

yes. even an empty one crashes after saving.

[H-MLim]

I found more weird thing...the whole plug crashes when I click any subpatches to open it (even subpatches in help file)...but it was OK when I right click it, and click 'open'.

[timothyschoen]

Thanks for reporting! I'm making some large optimizations to plugdata, but as a result I had to rewrite some core parts of the app. If you find any more issues, definitely report them so we can get back to stability again soon! Opening subpatches by clicking should be fixed now.

I can't reproduce the save crash yet, maybe it only happens on Windows?

[H-MLim]

thank you!

I can't reproduce the save crash yet, maybe it only happens on Windows?

oh no. that would be desperating if it's so. I'll attach the patch file just in case. this is just a blank patch, but it crashes as soon as try to type something on my computer (after creating object).

https://we.tl/t-KktR3kN3J1 (sorry for external link since I don't know how to upload pd files here. please let me know if it's expired)

If you find any more issues, definitely report them so we can get back to stability again soon!

absolutely!

[timothyschoen]

Hmm, unfortunately I still can't reproduce this. I'm testing on Windows 11. Would you be comfortable with building plugdata from scratch? That way we can see exactly were it crashes. I can guide you through the process if needed.

[H-MLim]

do you mean patching in plug, from scratch, and try it (save&load) again? if it's so, it still crashes on the recent nightly build (99a1e2388). strange...it seems it doesn't matter from plug or vanilla on my computer. once it saved, it crashes after Ctrl+1(create object)→typing anything. while old patches are fine. (by the way, the subpatch issue is solved. thanks!)

[timothyschoen]

No, I meant building your own plugdata from the source code. That way you can attach the debugger in Visual Studio, and see exactly where the crash happens. These are the steps:

1. Download and install:
   • Visual Studio Community Edition (this one will take a while, grab a cup of coffee)
   • cmake
   • git bash
   • python 3
2. Open git bash and paste this:

git clone --recursive https://github.com/plugdata-team/plugdata.git
cd plugdata
mkdir build && cd build
cmake ..  -G"Visual Studio 17 2022" -A x64

3. In explorer, go to USER_DIR/plugdata/build, open the "plugdata.sln" file with Visual Studio
4. In Visual Studio, you should have the "solution explorer" to the right. You have to look for the following targets

• pthread-VC3
• pd Right-click on them and hit "build", one by one. This will take a little bit of time, but not too long

5. Find the "plugdata_standalone" target in the list on the right, right click it and click "Set as startup project"
6. Now finally, hit the "play" button at the top to run plugdata inside the debugger. If you now do the thing that causes the crash for you, it should show you exactly where it goes wrong.

I can understand if it's too much for you handle, so don't worry if that's the case. It would be the most effective way of finding out why it crashes for you but not for me. One advantage is that once you have this set up, we can use this to find out what's causing any bug you encounter in the future.

[H-MLim]

hi. no problem at all. I tried to install them all, and paste the code you have written, but it seems plugdata.sln isn't installed, since git bash couldn't recognize the cmake with the error message "bash: cmake: command not found"

since my Windows settings are like this. so I should install cmake as "Windows x64 Installer:" right...?

Processor 12th Gen Intel(R) Core(TM) i7-1255U 1.70 GHz Installed RAM 16.0GB System 64 bit system, x64 based processor

Edition Windows 11 Home Version 23H2 OS Build 22631.2792 Experience Windows Feature Experience Pack 1000.22681.1000.0

[timothyschoen]

Ah, that's not a huge problem, sometimes cmake doesn't get seen by git bash.

Then, just open a regular windows "cmd" terminal, and do:

cd plugdata
git checkout develop
cmake ..  -G"Visual Studio 17 2022" -A x64

That should also work. Thanks for trying this, I hope we can find out what's wrong!

EDIT: added "git checkout develop" to it so you're on the develop branch

[H-MLim]

thank you! but in my computer, cmd outputs the error message:

'cmake' is not recognized as an internal or external command operable program or batch file.

what could be problem?

when I tried to run in Powershell, it outputs like this:

+ cmake ..  -G"Visual Studio 17 2022" -A x64
+ ~~~~~
    + CategoryInfo          : ObjectNotFound: (cmake:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

[timothyschoen]

Sorry that it's not going so smoothly!

Looks like it didn't install cmake into your search path. So what you want to do, find is where cmake was installed, and then you can do this in a cmd terminal:

C:\Program Files (x86)\CMake x.x\cmake.exe .. -G"Visual Studio 17 2022" -A x64

Where you need to replace "C:\Program Files (x86)\CMake x.x\cmake.exe" with wherever cmake is installed. (but it will probably be in one of the program files directories)

[H-MLim]

OK cool. so it seems I found the directory of cmake.exe from: C:\Program Files\CMake\bin

so should I turn on cmd, and just hit like C:\Program Files\CMake\bin\cmake.exe .. -G"Visual Studio 17 2022" -A x64 ? since it still outputs the error message like: 'C:\Program' is not recognized as an internal or external command operable program or batch file. could you let me know the detail process?

[timothyschoen]

We're almost there! I saw in a mail that you responded with

C:\Users\winds\plugdata>cmake .. -G"Visual Studio 17 2022" -A x64 CMake Warning: Ignoring extra path from command line:

".."

CMake Error: The source directory "C:/Users/winds" does not appear to contain CMakeLists.txt. Specify --help for usage, or press the help button on the CMake GUI.

This is fine, at least it's finding cmake now! The problem is that you're not in the "build" directory yet. My bad.

So

cd plugdata
cd build
cmake .. -G"Visual Studio 17 2022" -A x64

Also, the other error is because there is a space in the command. So if you do "C:\Program Files\CMake\bin\cmake.exe" .. -G"Visual Studio 17 2022" -A x64 it would also work. But I think the path issue is now solved, so this is no longer needed really.

[H-MLim]

ah, now it changes something! but it still has errors:

-- Selecting Windows SDK version 10.0.22000.0 to target Windows 10.0.22631.
-- Configuring juceaide
-- Building juceaide
-- Exporting juceaide
CMake Error at CMakeLists.txt:21 (_message):
  Could not locate module header for module
  'C:/Users/winds/plugdata/Libraries/melatonin_blur'
Call Stack (most recent call first):
  Libraries/JUCE/extras/Build/CMake/JUCEModuleSupport.cmake:440 (message)
  Libraries/CMakeLists.txt:20 (juce_add_module)


-- Configuring incomplete, errors occurred!

but the things is, this crashing problem is not appearing in the latest nightly build! (69268e2b2). so still wondering what was the problem. but will follow when the problem reappears. (btw let me know if you thing we should keep work on this) (it seems there are another problems on this build. so will report as another issue)

[timothyschoen]

Oh that's good news!

If you want to finish the building process for your own fun, you just need to run 'git submodule update', then you should be all good. But there no real need for that anymore fortunately. Thanks for trying though!

[H-MLim]

since the issue before was solved. I also write here about it for the future users who have same problem:

• install CMake with the option "Add CMake to the system PATH for all users"
• install Visual Studio with C++ develop tools
• go to git bash and hit git submodule update --init --recursive if it not works so well.

[ritaru]

I tried to build following the instructions above, and it seems the source has some issues when I try to run plugdata_standalone in VS 2022 for debugging purposes.

The issues follow.

Even with cmake --build ., C1128 error occured while building plugdata\Source\Dialogs\Dialogs.cpp. However, I managed to get over this by adding /bigobj in CMakeLists.txt's add_compile_options.

But this did not solve the problems I encountered and reproduced the errors in the image above.

The system details are below.

• Windows 11 Education N, 22H2 (build number 22621.3007)
• Microsoft Visual Studio 2022 Community Edition 17.0.1
• CMake 3.22.0

[H-MLim]

@ritaru ah. it seems finally it is fixed! thank you for your help so much. since @timothyschoen found critical tip, I'll poke here for those who would suffer same in the future

• Go into Source\Components\MarkupDisplay.h, and remove line 787: label.append(CharPointer_UTF8("‣"), font, defaultColour);

(by the way, for my computer, it was plugdata_core\Source\Utility\MarkupDisplay.h

[H-MLim]

so........summarizing our long journey:

1. Download and install:

• [ ] Visual Studio Community Edition ※ install C++ development tools together
• [ ] cmake ※ check the option CMake to the system PATH for all users
• [ ] git bash
• [ ] python 3 ※ check Add python.exe to PATH ※ hit python3 on Powershell and check if it installed well. if it's not, Powershell will show the new install page from Microsoft Store. install it.

2. Open git bash and paste this:

git clone --recursive https://github.com/plugdata-team/plugdata.git
cd plugdata
mkdir build && cd build
cmake ..  -G"Visual Studio 17 2022" -A x64

if it not goes well, go to Powershell and paste this:

git clone --recursive https://github.com/plugdata-team/plugdata.git
cd plugdata
mkdir build 
cd build
cmake ..  -G"Visual Studio 17 2022" -A x64

3. In explorer, go to USER_DIR/plugdata/build, open the "plugdata.sln" file with Visual Studio (most of case in Windows, it should be C:/users/(username)/plugdata/build

In Visual Studio, you should have the "solution explorer" to the right. You have to look for the following targets

• [ ] pthread-VC3
• [ ] pd

Right-click on them and hit "build", one by one. it must be in order of pthread-VC3 -> pd

Find the "plugdata_standalone" target in the list on the right, right click it and click "Set as startup project"

Now finally, hit the "play" button at the top to run plugdata inside the debugger. If you now do the thing that causes the crash for you, it should show you exactly where it goes wrong.

if it makes error like this,

C2001 newline in constant
C1075 "{": no matching token found
LNK1104 cannot open file 'Debug\plugdata_core.lib'

it is probably because you are using non-english locale system. change your Windows locale settings or simply go into Source\Components\MarkupDisplay.h, and remove line 787: label.append(CharPointer_UTF8("・"), font, defaultColour);

and play it again (rebuild pthread-VC3 -> pd recommended before play)

in every case of doing again from the scratch because it not goes well, it's recommended to delete and clear all files in plugdata\build folder.

[H-MLim]

I finally found what's the exact problem. I usually use my computer with Korean locale, and sometimes save my patch in desktop folder. it seems plugdata recognized desktop folder as non-latin charactered foldername (like '바탕 화면'), since Windows forces some folder names related with the locale system.

[timothyschoen]

I finally found what's the exact problem. I usually use my computer with Korean locale, and sometimes save my patch in desktop folder. it seems plugdata recognized desktop folder as non-latin charactered foldername (like '바탕 화면'), since Windows forces some folder names related with the locale system.

Oh, good to know! Do you have any idea how I could fix this?

[H-MLim]

unfortuantely I have no idea, since I don't know nothing about programming...but according to someone in Discord, it might be a problem of auto-suggestion. which means it probably crashes while seeking the folders and finding objects. what do you think about this?

(or.......just simply changing locale or not saving in the folders with non-latin name is OK for me although it wouldn't be a fundamental solution)

[ritaru]

@timothyschoen I would recommend putting a wrapper class for any kind of locale strings before to convert them into UTF-8, since there are thousands of Code Pages. JUCE does not provide any kind of conversion, so it needs to be done on plugdata.

The previous work here #192 uses only fallback fonts, but this time, the overall structure for handling strings must be amended.

So, to do so

1. Get system locale and code page on startup(if program is running on Windows)
2. Via wrapper class, convert every locale strings(paths, file names, etc) into UTF-8 before using
3. ... And happily use them.

If any help is needed, please, mention me.