Drew Bach

So, this has been driving me a bit nuts, and I'm going to go out on a limb and hope that it is pilot error. I started out with Max mainly with RNBO, and so most of what I've been able to figure out is trying to adapt Max knowledge into RNBO. 

So, most of my patches have been using Ableton Link for Tempo Sync and it is solid, but I've been trying to add a MIDI clock out to my FX patches as well from the Ableton Link transport clock. It works, but wowzers, the jitter is crazy. It isn't minor either, I'm getting massive jumps of 3-5bpm at times within a second or two. I've seen all sorts of references to using phasor, doing rounding, etc, but there have not been any example patches to learn from. 

The clock is made to always be sending, and have no notion of start/stop. This is intentional, as a lot of drum machines/synths take a few extra MS to catch the BPM before start, so by always sending I can prep the machines in advance. 

If someone could tell me what I am doing wrong I would be eternally grateful. 

(Note, if dropping into Max, remember that this is RNBO. So the Param object should be replaced.

Hi all,
So, this has been driving me a bit nuts, and I'm going to go out on a limb and hope that it is pilot error. 

rnbo-link-to-midi-clock-patch-jitter-help

Welp, I guess that I messed up the copy/paste patch....sorry!! I feel like such a dork. Since  it seems like I have not figured out copy/paste for patches, here is a pic of the patch as well:

{
	"boxes" : [ 		{
			"box" : 			{
				"maxclass" : "newobj",
				"text" : "t 248",
				"outlettype" : [ "" ],
				"patching_rect" : [ 254.0, 360.0, 37.0, 23.0 ],
				"numinlets" : 1,
				"id" : "obj-2",
				"numoutlets" : 1,
				"rnboinfo" : 				{
					"needsInstanceInfo" : 1,
					"argnames" : 					{
						"out1" : 						{
							"attrOrProp" : 1,
							"digest" : "Output order 1 (number).",
							"defaultarg" : 1,
							"isalias" : 0,
							"aliases" : [  ],
							"attachable" : 0,
							"isparam" : 0,
							"deprecated" : 0,
							"outlet" : 1,
							"type" : "number"
						}
,
						"triggers" : 						{
							"attrOrProp" : 2,
							"digest" : "The number of arguments determines the number of outlets. \t\t\t\t\t\tEach outlet sends out either a whole number, float, bang or list, \t\t\t\t\t\tas identified by symbol arguments (i, f, b, l). \t\t\t\t\t\tIf there are no arguments, there are two outlets, both of which send a float.",
							"defaultarg" : 1,
							"isalias" : 0,
							"aliases" : [  ],
							"settable" : 1,
							"attachable" : 0,
							"isparam" : 0,
							"deprecated" : 0,
							"type" : "list"
						}

}
,
					"inputs" : [ 						{
							"name" : "input",
							"type" : [ "bang", "number", "list" ],
							"digest" : "input to distribute",
							"hot" : 1,
							"docked" : 0
						}
 ],
					"outputs" : [ 						{
							"name" : "out1",
							"type" : "number",
							"digest" : "Output order 1 (number).",
							"defaultarg" : 1,
							"docked" : 0
						}
 ],
					"helpname" : "trigger",
					"aliasOf" : "trigger",
					"classname" : "t",
					"operator" : 0,
					"versionId" : -1133428571,
					"changesPatcherIO" : 0
				}
,
				"rnbo_extra_attributes" : 				{
					"triggers" : ""
				}
,
				"rnbo_uniqueid" : "t_obj-2",
				"rnbo_serial" : 3,
				"rnbo_classname" : "t"
			}

}
, 		{
			"box" : 			{
				"maxclass" : "comment",
				"text" : "MIDI Clock out",
				"patching_rect" : [ 242.5, 396.0, 102.5, 21.0 ],
				"numinlets" : 1,
				"id" : "obj-23",
				"numoutlets" : 0
			}

}
, 		{
			"box" : 			{
				"maxclass" : "comment",
				"text" : "Start/Stop clock",
				"patching_rect" : [ 155.0, 138.0, 128.0, 21.0 ],
				"numinlets" : 1,
				"id" : "obj-20",
				"numoutlets" : 0
			}

}
, 		{
			"box" : 			{
				"maxclass" : "newobj",
				"text" : "/ 20",
				"outlettype" : [ "" ],
				"patching_rect" : [ 246.0, 283.0, 31.0, 23.0 ],
				"numinlets" : 2,
				"id" : "obj-8",
				"numoutlets" : 1,
				"rnbo_extra_attributes" : 				{
					"hot" : 0
				}
,
				"rnbo_uniqueid" : "/_obj-8",
				"rnbo_serial" : 2,
				"rnbo_classname" : "/"
			}

}
, 		{
			"box" : 			{
				"maxclass" : "newobj",
				"text" : "metro @interval 1 ticks @active 1",
				"outlettype" : [ "" ],
				"patching_rect" : [ 172.5, 174.0, 190.0, 23.0 ],
				"numinlets" : 2,
				"id" : "obj-4",
				"numoutlets" : 1,
				"rnbo_extra_attributes" : 				{
					"lock" : 0.0
				}
,
				"rnbo_uniqueid" : "metro_obj-4",
				"rnbo_serial" : 2,
				"rnbo_classname" : "metro"
			}

}
, 		{
			"box" : 			{
				"maxclass" : "newobj",
				"text" : "transport",
				"outlettype" : [ "", "", "", "", "", "", "", "" ],
				"patching_rect" : [ 172.5, 237.0, 103.0, 23.0 ],
				"numinlets" : 2,
				"id" : "obj-1",
				"numoutlets" : 8,
				"rnbo_uniqueid" : "transport_obj-1",
				"rnbo_serial" : 1,
				"rnbo_classname" : "transport"
			}

}
, 		{
			"box" : 			{
				"maxclass" : "newobj",
				"varname" : "clockstart",
				"text" : "param clockstart @value 20 @enum stop start",
				"outlettype" : [ "", "" ],
				"patching_rect" : [ 45.0, 48.5, 250.0, 23.0 ],
				"numinlets" : 2,
				"id" : "obj-28",
				"numoutlets" : 2,
				"rnboinfo" : 				{
					"needsInstanceInfo" : 1,
					"argnames" : 					{
						"value" : 						{
							"attrOrProp" : 2,
							"digest" : "Set initial value",
							"defaultarg" : 2,
							"isalias" : 0,
							"aliases" : [  ],
							"settable" : 1,
							"attachable" : 0,
							"isparam" : 0,
							"deprecated" : 0,
							"type" : "number",
							"defaultValue" : "0",
							"label" : "Initial Value",
							"displayorder" : 3
						}
,
						"normalizedvalue" : 						{
							"attrOrProp" : 1,
							"digest" : "Set value normalized. ",
							"isalias" : 0,
							"aliases" : [  ],
							"attachable" : 0,
							"isparam" : 0,
							"deprecated" : 0,
							"inlet" : 1,
							"type" : "number"
						}
,
						"reset" : 						{
							"attrOrProp" : 1,
							"digest" : "Reset param to initial value",
							"isalias" : 0,
							"aliases" : [  ],
							"attachable" : 1,
							"isparam" : 0,
							"deprecated" : 0,
							"type" : "bang"
						}
,
						"normalized" : 						{
							"attrOrProp" : 1,
							"digest" : "Normalized parameter value.",
							"isalias" : 0,
							"aliases" : [  ],
							"attachable" : 0,
							"isparam" : 0,
							"deprecated" : 0,
							"outlet" : 1,
							"type" : "number"
						}
,
						"name" : 						{
							"attrOrProp" : 2,
							"digest" : "Name of the parameter",
							"defaultarg" : 1,
							"isalias" : 0,
							"aliases" : [  ],
							"settable" : 1,
							"attachable" : 0,
							"isparam" : 0,
							"deprecated" : 0,
							"type" : "symbol",
							"label" : "Parameter Name",
							"mandatory" : 1
						}
,
						"enum" : 						{
							"attrOrProp" : 2,
							"digest" : "Use an enumerated output",
							"isalias" : 0,
							"aliases" : [  ],
							"settable" : 1,
							"attachable" : 0,
							"isparam" : 0,
							"deprecated" : 0,
							"type" : "list",
							"label" : "Enum Values",
							"displayorder" : 6
						}
,
						"minimum" : 						{
							"attrOrProp" : 2,
							"digest" : "Minimum value",
							"isalias" : 0,
							"aliases" : [ "min" ],
							"settable" : 1,
							"attachable" : 0,
							"isparam" : 0,
							"deprecated" : 0,
							"type" : "number",
							"defaultValue" : "0",
							"label" : "Minimum",
							"displayorder" : 1
						}
,
						"min" : 						{
							"attrOrProp" : 2,
							"digest" : "Minimum value",
							"isalias" : 1,
							"aliasOf" : "minimum",
							"aliases" : [  ],
							"settable" : 1,
							"attachable" : 0,
							"isparam" : 0,
							"deprecated" : 0,
							"type" : "number",
							"defaultValue" : "0",
							"label" : "Minimum",
							"displayorder" : 1
						}
,
						"maximum" : 						{
							"attrOrProp" : 2,
							"digest" : "Maximum value",
							"isalias" : 0,
							"aliases" : [ "max" ],
							"settable" : 1,
							"attachable" : 0,
							"isparam" : 0,
							"deprecated" : 0,
							"type" : "number",
							"defaultValue" : "1",
							"label" : "Maximum",
							"displayorder" : 2
						}
,
						"max" : 						{
							"attrOrProp" : 2,
							"digest" : "Maximum value",
							"isalias" : 1,
							"aliasOf" : "maximum",
							"aliases" : [  ],
							"settable" : 1,
							"attachable" : 0,
							"isparam" : 0,
							"deprecated" : 0,
							"type" : "number",
							"defaultValue" : "1",
							"label" : "Maximum",
							"displayorder" : 2
						}
,
						"exponent" : 						{
							"attrOrProp" : 2,
							"digest" : "Scale values exponentially",
							"isalias" : 0,
							"aliases" : [  ],
							"settable" : 1,
							"attachable" : 0,
							"isparam" : 0,
							"deprecated" : 0,
							"type" : "number",
							"defaultValue" : "1",
							"label" : "Exponent",
							"displayorder" : 7
						}
,
						"steps" : 						{
							"attrOrProp" : 2,
							"digest" : "Divide the output into a number of discrete steps",
							"isalias" : 0,
							"aliases" : [  ],
							"settable" : 1,
							"attachable" : 0,
							"isparam" : 0,
							"deprecated" : 0,
							"type" : "number",
							"defaultValue" : "0",
							"label" : "Steps",
							"displayorder" : 8
						}
,
						"displayName" : 						{
							"attrOrProp" : 2,
							"digest" : "DEPRECATED: Use the lower case 'displayname' instead",
							"isalias" : 0,
							"aliases" : [  ],
							"settable" : 1,
							"attachable" : 0,
							"isparam" : 0,
							"deprecated" : 1,
							"type" : "symbol",
							"label" : "Display Name"
						}
,
						"displayname" : 						{
							"attrOrProp" : 2,
							"digest" : "A more readable name for the parameter in an external RNBO target",
							"isalias" : 0,
							"aliases" : [  ],
							"settable" : 1,
							"attachable" : 0,
							"isparam" : 0,
							"deprecated" : 0,
							"type" : "symbol",
							"defaultValue" : "",
							"label" : "Display Name",
							"displayorder" : 14
						}
,
						"unit" : 						{
							"attrOrProp" : 2,
							"digest" : "A symbol to describe the unit of the parameter in an external RNBO target",
							"isalias" : 0,
							"aliases" : [  ],
							"settable" : 1,
							"attachable" : 0,
							"isparam" : 0,
							"deprecated" : 0,
							"type" : "symbol",
							"defaultValue" : "",
							"label" : "Unit",
							"displayorder" : 15
						}
,
						"tonormalized" : 						{
							"attrOrProp" : 2,
							"digest" : "Converts a real parameter value to its normalized form.",
							"isalias" : 0,
							"aliases" : [  ],
							"settable" : 1,
							"attachable" : 0,
							"isparam" : 0,
							"deprecated" : 0,
							"type" : "symbol",
							"label" : "To Normalized Expression",
							"displayorder" : 10
						}
,
						"fromnormalized" : 						{
							"attrOrProp" : 2,
							"digest" : "Converts a normalized parameter into its actual parameter value.",
							"isalias" : 0,
							"aliases" : [  ],
							"settable" : 1,
							"attachable" : 0,
							"isparam" : 0,
							"deprecated" : 0,
							"type" : "symbol",
							"label" : "From Normalized Expression",
							"displayorder" : 9
						}
,
						"order" : 						{
							"attrOrProp" : 2,
							"digest" : "Order in which initial parameter values will be sent out on patcher load. The order can be numeric or symbolic ('first' and 'last')",
							"isalias" : 0,
							"aliases" : [  ],
							"settable" : 1,
							"attachable" : 0,
							"isparam" : 0,
							"deprecated" : 0,
							"type" : "symbol",
							"defaultValue" : "0",
							"label" : "Restore Order",
							"displayorder" : 12
						}
,
						"displayorder" : 						{
							"attrOrProp" : 2,
							"digest" : "Order in which parameters will show up in a list of all parameters. The order can be numeric or symbolic ('first' and 'last')",
							"isalias" : 0,
							"aliases" : [  ],
							"settable" : 1,
							"attachable" : 0,
							"isparam" : 0,
							"deprecated" : 0,
							"type" : "symbol",
							"defaultValue" : "-",
							"label" : "Display Order",
							"displayorder" : 13
						}
,
						"sendinit" : 						{
							"attrOrProp" : 2,
							"digest" : "Send initial value",
							"isalias" : 0,
							"aliases" : [  ],
							"settable" : 1,
							"attachable" : 0,
							"isparam" : 0,
							"deprecated" : 0,
							"type" : "bool",
							"defaultValue" : "true",
							"label" : "Send Init",
							"displayorder" : 4
						}
,
						"ctlin" : 						{
							"attrOrProp" : 2,
							"digest" : "MIDI controller number to control this parameter.",
							"isalias" : 0,
							"aliases" : [  ],
							"settable" : 1,
							"attachable" : 0,
							"isparam" : 0,
							"deprecated" : 0,
							"type" : "number",
							"label" : "MIDI Controller Number.",
							"displayorder" : 16
						}
,
						"meta" : 						{
							"attrOrProp" : 2,
							"digest" : "A JSON formatted string containing metadata for use by the exported code",
							"isalias" : 0,
							"aliases" : [  ],
							"settable" : 1,
							"attachable" : 0,
							"isparam" : 0,
							"deprecated" : 0,
							"type" : "symbol",
							"defaultValue" : "",
							"label" : "Metadata",
							"displayorder" : 17
						}
,
						"nopreset" : 						{
							"attrOrProp" : 2,
							"digest" : "Do not add this value to the preset [DEPRECATED - USE @preset 0 instead].",
							"isalias" : 0,
							"aliases" : [  ],
							"settable" : 1,
							"attachable" : 0,
							"isparam" : 0,
							"deprecated" : 1,
							"type" : "bool",
							"defaultValue" : "false"
						}
,
						"preset" : 						{
							"attrOrProp" : 2,
							"digest" : "Add this value to the preset.",
							"isalias" : 0,
							"aliases" : [  ],
							"settable" : 1,
							"attachable" : 0,
							"isparam" : 0,
							"deprecated" : 0,
							"type" : "bool",
							"defaultValue" : "true",
							"label" : "Include In Preset",
							"displayorder" : 11
						}

}
,
					"inputs" : [ 						{
							"name" : "value",
							"type" : "number",
							"digest" : "Parameter value",
							"hot" : 1,
							"docked" : 0
						}
, 						{
							"name" : "normalizedvalue",
							"type" : "number",
							"digest" : "Set value normalized. ",
							"docked" : 0
						}
 ],
					"outputs" : [ 						{
							"name" : "value",
							"type" : "number",
							"digest" : "Parameter value",
							"hot" : 1,
							"docked" : 0
						}
, 						{
							"name" : "normalized",
							"type" : "number",
							"digest" : "Normalized parameter value.",
							"docked" : 0
						}
 ],
					"helpname" : "param",
					"aliasOf" : "param",
					"classname" : "param",
					"operator" : 0,
					"versionId" : -1696900560,
					"changesPatcherIO" : 0
				}
,
				"rnbo_extra_attributes" : 				{
					"exponent" : 1.0,
					"ctlin" : 0.0,
					"tonormalized" : "",
					"displayname" : "",
					"minimum" : 0.0,
					"maximum" : 1.0,
					"sendinit" : 1,
					"fromnormalized" : "",
					"steps" : 0.0,
					"preset" : 1,
					"unit" : "",
					"meta" : "",
					"displayorder" : "-",
					"order" : "0"
				}
,
				"rnbo_uniqueid" : "clockstart",
				"rnbo_serial" : 2,
				"rnbo_classname" : "param"
			}

}
, 		{
			"box" : 			{
				"maxclass" : "toggle",
				"outlettype" : [ "int" ],
				"patching_rect" : [ 45.0, 95.5, 46.0, 46.0 ],
				"numinlets" : 1,
				"id" : "obj-85",
				"parameter_enable" : 0,
				"numoutlets" : 1,
				"rnbo_extra_attributes" : 				{
					"preset" : 0,
					"order" : ""
				}
,
				"rnbo_uniqueid" : "toggle_obj-85",
				"rnbo_serial" : 1,
				"rnbo_classname" : "toggle"
			}

}
 ],
	"lines" : [ 		{
			"patchline" : 			{
				"source" : [ "obj-28", 0 ],
				"destination" : [ "obj-85", 0 ]
			}

}
, 		{
			"patchline" : 			{
				"source" : [ "obj-85", 0 ],
				"destination" : [ "obj-1", 0 ]
			}

}
, 		{
			"patchline" : 			{
				"source" : [ "obj-8", 0 ],
				"destination" : [ "obj-2", 0 ]
			}

}
, 		{
			"patchline" : 			{
				"source" : [ "obj-4", 0 ],
				"destination" : [ "obj-1", 0 ]
			}

}
, 		{
			"patchline" : 			{
				"source" : [ "obj-1", 7 ],
				"destination" : [ "obj-8", 0 ]
			}

}
 ],
	"appversion" : 	{
		"major" : 8,
		"minor" : 5,
		"revision" : 6,
		"architecture" : "x64",
		"modernui" : 1
	}
,
	"classnamespace" : "rnbo"
}

Sorry about the paste above. It isn't actually a working one anyway, it works in max but not in RNBO. Here is the simplest clock patch. The results are identical using transport or a raw Metro feed, but ideally I would like to go this route as I am not using the transport in any of the patch. 

why do you need transport at all ?
is metro set to beatclock ticks interval and lock 1 
not supposed to follow host sync ?
I don't know if rnbo can sync well  that way, but using only needed objects
helps sometimes in max.

I don't use ableton and can't say if it makes sense to sync to live link and
generate another clock out of synced plugins.




I don't need transport, that is where I started at. The picture is where I'm at now. The clock in the pic is set to 20 ticks as the issue that I've found is that the / function works when using Max, but doesn't work when using RNBO. 

The idea is to be able to have the Pi send MIDI clock to hardware that is connected. Ableton Link is only for sending tempo to the Pi when using an application that sends Link but not MIDI clock.....which there are too many of. The clock works well when sending to RNBO, it is only when trying to send MIDI clock that things fall apart a bit due to jitter.

Hey Drew,

"most of my patches have been using Ableton Link for Tempo Sync and it is  solid, but I've been trying to add a MIDI clock out to my FX patches as  well from the Ableton Link transport clock."

So, do you mean that your patches running on the PI work fine with Link tempo sync, like generating audio etc there, but the MIDI clock out is jittery?

Are you using metro in your FX patches as well? Or.. what are you using there that does sync? phasor~?


Okay, I'm seeing an issue with midi event timestamps in the RNBO code.. I'll be looking into this

RNBO Link to MIDI Clock Patch Jitter-Help?

realshafer

Hi all, I'm using the RNBO JUCE template to build a simple stereo echo. Once built, the VST is categorized in Reaper as a VSTi. It should be a VST effect, not an instrument. I'm wondering if there's a way to specify this somewhere in the C++ code.

As a side question, I'm suspecting that there's a functional difference between VST and VSTi. My echo has a wet/dry mix. In Reaper, when set to 100%, I'm still hearing the dry signal. When testing in Max, 100% wet totally blocks the dry signal. Can anyone confirm that this is the expected behavior for VSTi? I'm hoping that if I can specify my build as a VST effect that the 100% wet mix will function correctly.

Hi all, I'm using the RNBO JUCE template to build a simple stereo echo. Once built, the VST is categorized in Reaper as a VSTi. 

rnbo-building-vst-effect-vs-vsti

i dont know offhand where, but yes, instrument or effect it is an attribute of VST plug-ins.

i think it is called IsInstrument (just like the message for the call in the max object) and you should find it under PlugInCharacteristics in JUCE.

the main difference is where they show up in some hosts and that instruments did not support audio-in (at least that was true for VST 2.x)

i have hacked most instruments in classic MacOS the other way round back in the days; to make them show up as effects - so that i can open more instruments than the host program suggested. it is a single byte you have to change, so you can also do it later in the build (if you know where to look)

regarding audio through options, every host handles that different. many DAWs for example have special send effects slots, while vst~ in max is of course always an insert effect.

if you implement a custom send effects routine in max, the "pass audio when plug-in is turned off" option of vst~ does no longer make any sense.


Thanks Roman! I'm looking at PluginCharacteristics now and everything is unchecked (including "Plugin is a synth"). Additionally, under Plugin VST3 Category "Fx" is selected. Searching through the generated code, I see many instances of IsInstrument = false. So, I'm still perplexed.

RNBO building VST effect vs VSTi

ShelLuser

Hi gang!

First if all: huge compliments for RNBO~... I'm still very much a newbie at the time of writing but I already managed to build, and use, a very crude VST3 plugin and... it's just amazing. See: I use both Live (suite) & FL Studio side by side and while I have M4l in Live I always fantasized about what might happen if you could use Max with DAW's like 'FLS'. Now I can!

Question... everything works as expected but I'm wondering if it would be possible to 'overrule' the cloud compiler and instead use a locally set up compiler & framework? Or is this approach fully hardcoded into RNBO?
 
Note: I'm not necessarily asking how it can be done, merely if...


(edit): Thanks for the feedback!  I overlooked that option and I can easily imagine that this will make it much easier for people to filter stuff. Not gonna respond because we don't need a "ping", so... figured I'd just edit.

Hi gang!

First if all: huge compliments for RNBO~... 

would-it-be-possible-to-use-a-local-compiler-for-vst3-targets

So, yah, in hindsight this was a bit of an obvious question I suppose... 

First things first: the export sidebar features 2 options for "Source code" where the 1st option is C++ source code export. That's an obvious approach.

Second... having already experimented with VST exports (and being very impressed with it) you'll quickly learn that VST builds are powered by Juce; a "framework for audio applications and plug-in development". Best part is obvious: it can be downloaded and used for free, which is something that Cycling '74 is doing.

And there's my answer. Of course I still need a compiler for all this, but that's something which Visual Studio can handle for me.

Thanks for answering you own questions so that others with the same question can have a quick hint on what to to.
Instead of editing the title als ‚(solved)‘ there is a resolved tag you can give to the topic instead. ;)

Here is the JUCE adapter code that we bundle with the RNBO source code: https://github.com/Cycling74/rnbo.adapter.juce 
and here is a template project that we provide for creating your own customized JUCE/RNBO based projects: https://github.com/cycling74/rnbo.example.juce


Would it be possible to use a local compiler for VST3 targets?

Austin Franklin

I’ve gone through the Learn documentation and the web template for rnbo~, and can’t find anything about using microphone input from a device to feed audio into a patch. Does the in~ object work with the Web Export, or is there additional code in JavaScript/HTML that is need to engage the microphone of the device? For reference, I want to prototype a website that can be accessed by a mobile phone and take in audio and process it.

I’ve gone through the Learn documentation and the web template for rnbo~, and can’t find anything about using microphone input from a ... 

microphone-input-in-rnbo-with-web-export

you are right that there currently isn't a specific example that shows how to do that but happy to help. One can think of accessing the microphone and creating the audio stream that will be fed into your exported RNBO patch as a responsibility of the host (in your case the website / app). For achieving this WebAudio provides the concept of a MediaStreamAudioSourceNode that can then be connected to your RNBO device.

There is a few small steps involved to get there, partially in order to ensure the user's consent / privacy for accessing the mic.  I've put a simple example up here: https://codepen.io/team/cycling74/pen/RwEKOVz/0f3a02def2a7e49f074fcfff33ddf65b 

To run the page click the "start" button to enable microphone input and then adjust the "gain" slider to control the gain of the output of your microphone input.

The RNBO patch itself is just a simple passthrough with a gain control:

Fantastic. Thank you for your help, this makes total sense. I occasionally ran into a TypeError issue setting the gain with .normalizedValue in my browser, but eventually got it working. A "Gain" param just after the in~ object in rnbo~ worked in the meantime.

I'm wondering if you've noticed any issues with synthesis in browsers? For instance, a single sine tone results in glitching for mobile devices only and works fine on a laptop. I have an example of my issue here: https://github.com/austinfranklin/rnbo-test/settings/pages

Curious if I'm doing something wrong in rnbo~ (although I'm just running a single sine wave with a gain parameter) or if there is an issue with efficiency on a mobile phone?

Microphone Input in rnbo~ with Web Export

Jelani Thompson

I'm currently building a chord trigger device in RNBO that allows you to select the note and choose a corresponding chord formula to play the chord related to said note. The format is like this:

```
"blues" : [ 0, 3, 5, 6, 7, 10 ],
"5th-mode-of-harmonic-minor" : [ 0, 1, 4, 5, 7, 8, 10 ],
"5th-mode-of-harmonic-major" : [ 0, 1, 4, 5, 7, 9, 10 ],
"dominant-bebop" : [ 0, 2, 4, 5, 7, 9, 10, 11 ],
"dominant-diminished" : [ 0, 1, 3, 4, 6, 7, 9, 10 ],
```

RNBO doesn't have access to dict or coll, but the documentation states that this can be worked around by using list.reg (https://rnbo.cycling74.com/learn/working-with-lists). The thing is, I have a lot of key-value pairs, and I could see list.reg getting pretty long when I start adding in the chord formula numbers. 

Example with only 4 chord formulas:

list.reg "0356710", "01457810", "01457910", "0245791011"

This could be fine with a few, but might start to get messy once you have something like 50+ chord formulas.

Is there a better way to store these key-value pairs in a way that doesn't lead to a lot of visual clutter?

Will give list.coll a try in the meantime.

Thanks!



chord-formulas.json

Hello!
I'm currently building a chord trigger device in RNBO that allows you to select the note and choose a corresponding chord formula to ... 

rnbo-key-value-pairs-with-listreg

RNBO Key-Value Pairs with list.reg

This is a feature request really: It would be great to have the feature set of rnbo's [param] object added to the gen-inside-of-rnbo's [param] object. For example, it is super convenient to turn on the @exposeparams attribute of a gen~ object. But, when exporting to a VST, the naming of those parameters is ugly. It would be great to be able to use the same attributes as rnbo's [param] like @displayname, @displayorder, @unit, @fromnormalize, @tonormalize, etc.

Yes, I know I can build the [param] with those attributes outside of gen~ and use the [set] message to connect. It just seems like the experience could be less redundant, especially since @exposeparams seems to point in this direction.

Hi all,
This is a feature request really: It would be great to have the feature set of rnbo's [param] object added to the ... 

gen-inside-rnbo-exposeparams-and-displayname

gen~ inside rnbo~ @exposeparams & @displayname

SSingh

I am trying to modify the RNBO Wavetable Synth example to dynamically change the Buffer reference in the Gen code.   I want to do it from within RNBO so I can change the Wavetables from within a plugin when I export it.  The Wavetable Synth example comments say: "Requires a buffer named osc_wavetable_buf or new references in the gen~ patcher".  I can easily change the reference a single time within the code itself, or from outside RNBO in the Max patch with Peek/Poke.  Peek/Poke does not seem to be working from within RNBO for some reason.  Am I missing something? Is there another way to do this?  

I am trying to modify the RNBO Wavetable Synth example to dynamically change the Buffer reference in the Gen code. 

changing-buffer-reference-in-rnbo-gen

Ok, seems I figured it out.  The signal Peek/Poke objects don't work for some reason in RNBO, even though I had them setup exactly as I do in Max (is this a bug? or is there something I'm not understanding?).  I just tried the standard Peek/Poke to change the wavetable buffer within RNBO and it finally works.  If there are any other better suggestions about this, I am curious to know!

Now I'm beginning to think my problems have all just been bug related: when I start my RNBO patch fresh, the peek/poke does not work.  When I copy and repaste the peek/paste objects again after freshly reopening the patch, they work as expected.  Many hours of solid frustration because of this! Am I missing something here, or is this a bug?

Ok, it was a bug.  The newest RNBO update fixes sample initialization.  Still curious to know if there are any other ways to change the reference of a named buffer in Gen within RNBO.  Are there other ways than peek/poke?

Changing Buffer Reference in RNBO Gen

Jonatan Krogh

Im using Splat~ with @overdubmode accum. If i record at standard speed it all works well, but if i record at lower speed so the interpolation kicks in, then the overdubbed sound gets louder. The slower it records, the louder and glitchier it gets. 

Also, Im using the trick from the iPoke documentation of connecting a signal from the patcher playing back the sound to the poker, to force it to play before recording. Seems a bit dodgy though so would love to know if there's a better solution.

jkPoker_test.maxpat

Im using Splat~ with @overdubmode accum. 

splat-overdub-gets-louder-when-interpolating

I think this may be expected behaviour?  If you slow the write speed down, then you are effectively pouring more samples into an equivalent space of the buffer.  Imagine you are icing a cake: the slower you move the icing tip, the thicker the icing will be, because more of it accumulates on top of each other. 

If it helps: The splat~ op in gen basically just spreads the input sample value between the two nearest sample slots in a buffer, with a linear mix between them, and the overdubmode=accum means that it adds to the existing data in the buffer.  

If you wanted to counteract this and balance the amount regardless of the speed, you'd need to attenuate the signal before it goes into splat~, with some factor that inversely proportional on the write speed.  

Thats what i thought was going on behind the scenes too, but it doesn't seem like the most intuitive behaviour or something I'd do on purpose, more like an oversight. 

I implemented this in the example, and it does indeed seem to work as expected when overdubbing. If this is the intended functionality, why is it only happening when overdubbing, and not when replacing? If overdub is zero, it's recording at normal volume, so to get the "expected" behaviour i need to interpolate between 1 and the speed-compensated gain. (second example).

Another confusing behaviour is that if record with overdub 0.  (replacing) at low speed, then jump to a higher speed, the old audio stays. Again the behind the scenes explanation makes sense, it's just skipping samples, but since it's supposed to be "interpolated overdubbing", this is not what i would expect. 

Splat~ Overdub gets louder when interpolating. 

As the title says. Can't use RNBO to work in standalones. Is this intended or a bug? 

I tried using a workaround to just export an external, but I'm referencing several buffers in the rnbo~ patcher and the external doesn't seem to like that (or something else is wrong with my external but my guess is this is the issue), so in my specific case that's not an option. 

As the title says. Can't use RNBO to work in standalones. 

standalone-using-rnbo-doesnt-work-tells-me-rnbo-no-such-object

rnbo as well as node for max packages must be included into standalone for rnbo to work.
one can trash a lot of parts from packages to reduce standalone size,
but essential parts need to remain, otherwise rnbo can't work.
which makes absolute minimum of at least 300 MB size even for simplest standalones on windows, and even more on Mac, if you leave both arm and intel code intact.


Jonatan,

The exported external shouldn't have any issue referencing several buffers, by default you have to map your external's buffers to max buffers, but beyond that it should really not be any different than rnbo~.

If you're having issues with that, we'd love to know.


Do i need to do something extra to include RNBO and Node in the standalone? I have not removed anything to make it lighter yet. 

Here is my test patch.
If i just build this to a standalone i get "rnbo~: no such object. 
If i export the rnbo patch as a max external it does nothing.



you need to reupload your test  patch, it is only a bookmark of the file.
either select all and copy compressed, then paste here, 
or zip it before uploading.
-----
open your standalone and look in resources/packages folder.
If there are not there, copy both rnbo and node for max folders into packages folder.

Way better is to use external than rnbo, which makes standalone
start very slow, and increases app size.

I loaded your external on windows,
it shows audio, signal #2 and overdub inlets, but
no outlet.
-------
Before making standalone, your first test should be your external in max itself.
if it does not work than you need to fix that first.


oh sorry, here's the real one!

It doesn't use the outlets... its kinda a replacement for poke, only i have to bake the buffer names into the object since i can't work with strings in RNBO if i understand things correctly. It makes sense when you see the patch i think. 

I've only tested the external in max, didn't try exporting since i didn't get it to work. When i try i simply export the external with default settings, then just change the name of the rnbo object to replace it. All outputs are matching and no errors, but nothing is happening to the buffers.



I looked at it, no idea if compiled external can cope
with buffers set like that.

but as standalone with rnbo patch it runs, although very sluggish,
it takes long to start app, and also long till recording starts functioning.

one has to manually copy both packages into standalone,
at least on windows they don't get auto included.


Ok, thanks, I'll give it a try. 

@Alex Norman, would be great if you could have a look at the external and help me figure out what the problem is. My only guess is the buffers since there's not much else going on in the patch, and Source Audio seem to share that suspicion.. 

I haven't looked deep into your patch to get all the details but I think that the max external export works as expected, you just have to map the buffers as I indicated earlier.

[pokertest1~ @T1 T1 @T2 T2 @T3 T3 @T4 T4 @T5 T5 @T6 T6 @T7 T7 @T8 T8]

Basically, the exported external doesn't automatically map a "rnbo" buffer, say T1 here, to the max buffer T1, because, for instance, if you're creating a sampler and want to have a bunch of instances of your external playing different sound sources, that would but unnecessarily limiting. Instead, the external provides you with an attribute that you use to map the "rnbo buffer" to a max buffer by name.. so for instance, your patch that uses [pokertest1~] could have a [buffer foo 5000] and you could use that via [pokertest1~ @T1 foo] to map the RNBO T1 buffer to "foo" in max.

Using the exported external in your standalone will really improve the user experience vs using rnbo~.


Ahaa! Thanks, that works! Great news! Don't need to use 8 different buffers at all then, i can just use one and remap it.

Please note that without access to your specific Max/MSP patcher and environment, it's challenging to pinpoint the exact issue. The suggestions above are general troubleshooting steps to help you get started in resolving the problem with the RNBO object in standalone applications.

Standalone using RNBO doesn't work. Tells me "rnbo~: No such object"

Hegel Pedroza

I'm interested in building a web-based interactive MIDI interface using RNBO. In the past, I've used the "this.patcher" object in Max to dynamically create new objects and customize interactions through JavaScript. Now, I want to achieve a similar capability in RNBO, where I can enable users to create multiple buttons, sliders, and other interactive elements.

Could you please guide me on how to accomplish dynamic patching in RNBO and how I can use JavaScript to customize object creations and interactions within the interface? I aim to create an intuitive MIDI interface that allows users to generate as many buttons and sliders as they need.

Thank you for your assistance! Looking forward to your advice.

Hi there,
I'm interested in building a web-based interactive MIDI interface using RNBO. 

Cycling '74 Forums

Okay, I'm seeing an issue with midi event timestamps in the RNBO code.. I'll be looking into this

Thanks Roman! I'm looking at PluginCharacteristics now and everything is unchecked (including "Plugin is a synth").

Here is the JUCE adapter code that we bundle with the RNBO source code: https://github.com/Cycling74/rnbo.adapter.juce and here is a ...

Hey again, I'm wondering if you've noticed any issues with synthesis in browsers? For instance, a single sine tone results in glitching for ...

Hello! I'm currently building a chord trigger device in RNBO that allows you to select the note and choose a corresponding chord formula to ...

Hi all, This is a feature request really: It would be great to have the feature set of rnbo's [param] object added to the ...

Ok, it was a bug. The newest RNBO update fixes sample initialization.

Thats what i thought was going on behind the scenes too, but it doesn't seem like the most intuitive behaviour or something I'd do on ...

Ahaa! Thanks, that works! Great news! Don't need to use 8 different buffers at all then, i can just use one and remap it.

Hi there, I'm interested in building a web-based interactive MIDI interface using RNBO.