I have a Pd patch which calls in a second patch as an abstraction.
The second patch works fine by itself. But when I try to use it from inside the first, I'm seeing this
signal outlet connect to nonsignal inlet (ignored)
error. But I can't see WHERE it's happening.
Doing "Find last error" just gives me.
... sorry, I couldn't find the source of that error.
How can I find out which two objects Pd is referring to with that outlet / inlet?
(The outlets of the subpatches are being wired into [dac~] in the main patch)
These subpatches USED TO work, until I tried to add Open Sound Control to them with udpreceive. And, like I say, they still do work, accepting the OSC if I run them on their own.
actually, Pd (>=0.43) became quite good at locating the source of errors, but unfortunately this is little known (and less documented).
if you get a findable error (usually those in red; and the error you get is one of them!), you can click on the error-line and it will take you to the object that complained (and select it)
the actual click-sequence is OS-dependent:
linux: Ctrl+LeftMouseButton
w32 : Ctrl+LeftMouseButton
OSX : ⌘+LeftMouseButton
alternatively you can get to the error, by clicking on the error-message and then hitting
Return
(Enter should work as well).
Related
I'm unable to understand how the mock-debugger extension controls where the next step is.
For example what if I'd like to step 2 lines if I find the word "banana" in my text? Also, I'd like to do something, like "Step In", where I can walk word-by-word - is it possible?
I've seen the this._currentLine = ln; assign, which looks like it controls where the line is, but it's just a simple local variable. How could it ever control anything in the debugger? I can't find any other uses of the _currentLine varbiable where it passes to anything useful API (except for stack tracing, but I don't think it has any relation with the debugger line-control).
The stack trace is the only source for the debugger step visualization. When the debugger gets a notification to pause it requests the current stack trace. The TOS determines where the next execution point will be located. Hence the debug adapter is reponsible to determine this position precisely.
I am toying with the FluidEnter/FluidExit. So in a simple form, here is what I am trying to do:
I created in Main an empty population of agent called Terminal. For now, in Terminal, there is only a fluidEnter connected to a fluidExit (very simple)
enter image description here
Now, on startup, I want to fill this population and set up the proper connections (the terminals are ordered).
So, on startup, I call a function init(), whose body start with Terminal t = add_terminals(); (I have only one terminal for now, just toying with things)
In Main, obviously, I also have a fluidEnter and a fluidExit. I would like to connect the fluidExit of Main to the fluidEnter of the terminal t, and the fluidExit of the terminal t to the fluidEnter of Main, so code (still in init()) looks like
fluidExit.set_fluidEnter(t.fluidEnter);
t.fluidExit.set_fluidEnter(fluidEnter);
I get an exception so obviously, I am doing something wrong. Any idea?
I think the set_fluidEnter function is deprecated or just non-functional.
Instead, you should do:
fluidExit.connect(t.fluidEnter);
So just replace set_fluidEnter with connect... nothing else.
That should do the trick
I was going down the same path as you a couple of months ago. Yes... .connect() works great. It even works as a gate. If it is disconnected, then fluid stops at the exit. Once connected, fluid starts to flow again. It is very slick.
I am trying to make a patch that plays audio when a bang is pressed. I have put a symbol so that I don't need to keep reimporting the file. However it works sometimes but not all the time.
A warning in the Pd console reads: Start requested with no prior open
However I have imported an audio file
Is there something that I have done wrong?
Use [trigger] to get the order-of-execution correct.
One problem is, that whenever you send a [1( to [readsf~] you must have sent an [open ...( message directly beforehand.
Even if you have just successfully opened a file, but then stopped it (with [0() or played it through (so it has been closed automatically), you have to send the filename again.
The real problem is, that your messages are out of order: you should never have a fan-out (that is: connecting a message outlet to multiple inlets), as this will create undefined behavior.
Use [trigger] to get the order-of-execution correct.
(Mastering [trigger] is probably the single most important step in learning to program Pd)
I am using ispin and got an error stating spin: trails end after 10 steps and transition fail.
How can I prevent this error from happening?
You prevent the error from happening in one of two ways:
fix your Promela model - you have a bug in your Promela that needs to be removed
you've found an error in the system that you are modeling. Congratulations. You now report the error to the person in charge of the system that you are modeling.
In practice, when you have a trail indicating an error, you next perform
spin -p -t <name of the model>.pml
which will print out the step by step model executions that lead to the error. You scour them to confirm that they are correct - if so, see #2 above; if not correct, see #1.
I had the same problem and it is fixed after putting -DVECTORSZ :
in the advanced parameters settings window of verification tab.I have also increased the physical memory to 2048.
I have a bit of an annoyance rather than a major problem, that I would like to tackle. I have a subsystem that creates a bus inside it and outputs it via a Scope. The bus creation is through From tags, that depend on signals from other components.
Now, when I don't have those components, I get a warning saying something like:
Warning: Selected signal 'Compressor' in 'untitled/Pressure/Bus Selector'
originates from an unconnected source signal
entering 'untitled/Output Data/Bus Creator12' at input port 1
It seems there is no way to turn this off in the Diagnostics pane (Connectivity sub-pane or otherwise). It seems it was a bug in very old versions of Matlab, but was fixed in R13, according to these links:
Link 1,
Link 2 (search for "unconnected source signal" on the page)
I'm using 2013a, a full 12 years later. Anyone have more information on how I can turn this warning off?