Closed ghost closed 6 years ago
Maybe it is also nice to add an option to show the parameter values /after/ conversion as well:
; VOICE AREA instr 1 ; Module Parameters Inlets Outlets LfoA 0.26,0,0,0.516,2,1,4,2, 1, 7 Out2 0,1,0, 7,7 LfoC 0.64,0,4,2,1, 1, 0 OscA 1.0,0.0,1,1.0,2,0,3, 1,7, 7
That way it can be checked if the right conversions are used... On 25/02/18 23:38, Eugene Cherny wrote:
Currently, the only way to see parameters of a module is by printing the contents of a patch using the |-p| argument, like this
|$ pch2csd -p lfoA2OscA.pch2 Patch file: lfoA2OscA.pch2 Modules Name ID Type Parameters Area ------ ---- ------ ------------------------- ------ LfoA 1 26 [0, 0, 0, 66, 2, 1, 4, 0] VOICE OscA 4 97 [64, 64, 1, 127, 2, 0, 3] VOICE Out2 2 4 [0, 1, 0] VOICE LfoC 3 24 [64, 0, 4, 2, 1] VOICE Cables From To Color Type Area ----------------- -- ---------------- ------- ------ ------ LfoA(id=1, out=0) -> OscA(id=4, in=1) blue out-in VOICE OscA(id=4, out=0) -> Out2(id=2, in=0) red out-in VOICE OscA(id=4, out=0) -> Out2(id=2, in=1) red out-in VOICE |
This represents parameters as an array of number ordered as they appear in the patch. To figure out to what UI element each parameter corresponds to, one would need to twiddle something in the NM editor, save the patch, print its contents again and compare the changes.
This is a bit tedious and error prone when creating special annotations for UDOs. To improve this we can print human-readable names of the parameters in the order they appear in a patch. There is an XML file flying around on the internets, supposedly with module parameters listed together with human-readable labels. @gleb812 https://github.com/gleb812 knows about it. We need to find it, parse, add as metadata to the converter, and add some command-line parameter that would allow to access it.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gleb812/pch2csd/issues/6, or mute the thread https://github.com/notifications/unsubscribe-auth/AFkYZzQ3i6wCgX0kcL85V5GaFUecMPgAks5tYeDIgaJpZM4SSfnQ.
Hey guys,
I checked the source code for ModuleDef.xml
[1]. Unfortunately, I wasn’t able to find a license for that project. That means technically we aren’t allowed to use this file in our MIT-licensed codebase. Maybe we can write an author and ask if he or she is willing to change the license for it?
Euge, this is https://sourceforge.net/projects/nmg2editor/files/v0.21/
OK, I noticed that there is a notion of GPLv2. I personally hate this license as it poisons all the code. Are we willing to relicense the project to GPLv2?
Can we stay with MIT, but use that file somehow?)
No, that’s the point of GPL. If you use a GPL-licensed library, you should license your code with GPL. Contagious shite.
OK then. We can just exclude the file.. )
Btw @gleb812, maybe you could write the author and ask him to relicense this file for us? :)
OK. me try.
Could someone help me with this? I cannot sync to pch2csd. Something with ssh keys maybe? Should I be added somewhere first? I am using the GitHub Desktop app on OS X...
On 04/03/18 16:46, gleb812 wrote:
OK. me try.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/gleb812/pch2csd/issues/6#issuecomment-370239079, or mute the thread https://github.com/notifications/unsubscribe-auth/AFkYZy3bJX3xkusj0vD4BVap-REwsuh8ks5tbAxCgaJpZM4SSfnQ.
Hey @zappfinger, could you print the error you’re having?
It is a popup with
"Authentication failed, You may not have permission to access pch2csd. Check Preferences to make sure you’re still logged in."
I am logged in and can sync with my own Repo..
On 04/03/18 16:58, Eugene Cherny wrote:
Hey @zappfinger https://github.com/zappfinger, could you print the error you’re having?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gleb812/pch2csd/issues/6#issuecomment-370240078, or mute the thread https://github.com/notifications/unsubscribe-auth/AFkYZ3cR5emYLC_D5q8T57CSE7oD-cdUks5tbA81gaJpZM4SSfnQ.
@zappfinger I added you as a collaborator for this repo. Now you shouldn’t have this issue.
Thanks! It seems to work indeed...
Richard
On 04/03/18 17:11, Eugene Cherny wrote:
@zappfinger https://github.com/zappfinger I added you as a collaborator for this repo. Now you shouldn’t have this issue.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gleb812/pch2csd/issues/6#issuecomment-370240987, or mute the thread https://github.com/notifications/unsubscribe-auth/AFkYZ-kPVgwANbMbqTG3GwBHzvg70-5Yks5tbBIvgaJpZM4SSfnQ.
@zappfinger I just added an ability to see mapped values. Check the -m
keyword argument. Example:
pch2csd -m 1 voice ~/test_modes_LfoC.pch2
Patch: ~/test_modes_LfoC.pch2
Details of the module:
Module(type=24, type_name=LfoC, id=1, location=Location.VOICE_AREA, modes=[0])
Type Raw Mapped
--------- ----- --------
Parameter 0 62.9
Parameter 0 0
Parameter 4 4
Parameter 1 1
Parameter 1 1
Mode 0
This representation can also be improved by replacing strings “Parameter” and “Mode” with the actual names from the XML file we were talking about.
Nice!
On 04/03/18 19:50, Eugene Cherny wrote:
@zappfinger https://github.com/zappfinger I just added an ability to see mapped values. Check the |-m| keyword argument. Example:
|pch2csd -m 1 voice ~/test_modes_LfoC.pch2 Patch: ~/test_modes_LfoC.pch2 Details of the module: Module(type=24, type_name=LfoC, id=1, location=Location.VOICE_AREA, modes=[0]) Type Raw Mapped --------- ----- -------- Parameter 0 62.9 Parameter 0 0 Parameter 4 4 Parameter 1 1 Parameter 1 1 Mode 0 |
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gleb812/pch2csd/issues/6#issuecomment-370253287, or mute the thread https://github.com/notifications/unsubscribe-auth/AFkYZworj8DGpTjKr7QgLRem_8qiYDXIks5tbDeAgaJpZM4SSfnQ.
Human-readable names will be implemented as part of #11.
Currently, the only way to see parameters of a module is by printing the contents of a patch using the
-p
argument, like thisThis represents parameters as an array of number ordered as they appear in the patch. To figure out to what UI element each parameter corresponds to, one would need to twiddle something in the NM editor, save the patch, print its contents again and compare the changes.
This is a bit tedious and error prone when creating special annotations for UDOs. To improve this we can print human-readable names of the parameters in the order they appear in a patch. There is an XML file flying around on the internets, supposedly with module parameters listed together with human-readable labels. @gleb812 knows about it. We need to find it, parse, add as metadata to the converter, and add some command-line parameter that would allow to access it.