I've created a Pure Data abstraction which takes 5 MIDI controller IDs as arguments, and has two inlets (velocity and MIDI controller). I use spigot to output the input velocity at outlet i if the MIDI controller ID matches the i th argument to the abstraction.
I use this to control 5 sliders (volume, attack, decay, sustain, release) from my MIDI controller, which look like this:
As you can see, the abstraction is very repetitive, and ideally it would be able to take n arguments, outputting the slider value of the given MIDI slider at the i th outlet. Alternatively I could just use a single argument and use the abstraction anew for each slider, but that's a bit repetitive too.
Is there a way to take n arguments in my abstraction? Or, is there any other more elegant solution to control sliders from MIDI that I'm missing?
For core vanilla objects or externals it is a common feature to take a variable amount of arguments. Many objects like [trigger], [select], [pack] or [unpack] behave this way and create a number of xlets according to how many arguments they are given.
For abstractions however, there is no simple way to have a variable number of outputs depending on the number of arguments given. It's possible, but it's rather a hack.
Let's first look at some techniques to make the patches easier.
As you can see in the following screenshot the [expr] object in your patch can easily be substituted by a simple Pd object: [==]
Let's look at the MIDI messages. MIDI objects output the elements of the hierarchical tree: channel, controller, value in this order but from right to left (true for all objects in Pd, the rightmost outlet fires first). What you want is routing them according to the controller number, ignoring the channel number. For this you need to flip the order of the two first outlets so you can use the controller number as a selector in a list. One way to do this is to pack the numbers and then reorder them in a message using the dollar symbols (careful, dollar symbols in message objects operate on local messages, they have nothing to do with what dollar symbols do in object boxes). Another method would be to use the object [swap] (using [swap] in this case would reduce the number of objects by one in the patch, but the [pack] and [message( is more versatile, that's why I show it here).
Regarding the actual question of taking n arguments to change the number of outlets: This challenge are two separate problems:
How to detect the number of arguments
How to change the number of outlets dynamically
Until recently there hasn't been a way proper way to detect the existence of arguments. Since Pd 0.50 there is [pdcontrol] which allows exactly this.
Using [initbang] here because [loadbang] would fire too late for creating the outlets.
The second part of the challenge may be solved either through a technique called 'dynamic patching' or by outputting a list instead of creating additional outlets. However with a list output you'd need to route it afterwards and then you'll arrive quickly at the patch pictured above.
Related
I'm building a class (sorry - Agent) that will work with a set of Tank objects (Fluid Library) - doing things like monitoring individual levels or total level of all tanks, reporting on levels and initiating actions based on levels - things of that nature. For argument's sake let's call it a "TankMonitor" agent.
Ideally I'd like to be able to define a Parameter in my "TankMonitor" agent that allows me to define the tanks of interest when I place a TankMonitor in main. I have tried to define the type of the parameter as Other - ArrayList<Tank> however I don't know how to set up the next step to allow me to populate the ArrayList of Tanks when I put an instance of this agent in main. My preference would be to have a list type control to populate the ArrayList - much like the way the AnyLogic Seize block allows you to specify multiple resource pools to choose from.
Has anyone attempted this before and been successful?
This is possible as follows:
Change the type to "Other" and then 'Tank[]' , i.e. an Array of Tanks
Change the control type to "one-dimensional array"
Example below. Now you have the same UI to pre-define tanks at design time for your agent instance.
In addition to Benjamin's perfect answer, I'd just add the manual workaround, which is not needed here but can be useful when the parameter in question has a more complicated structure than covered by the pre-made controls, say a list of lists, a map, or similar.
In such a case, the Control Type is still Text, and populating it in an instance happens by pointing it to a new object of the parameter's type. E.g. for an ArrayList<Tank> parameter, you might instantiate a new ArrayList object, which you fill with a list of objects like so:
new ArrayList<Tank>(Arrays.asList(tankA, tankB))
In the Java code, whatever is written into that text box will end up on the right side of a parameter assignment statement in the embedded Agent instance's auto-generated parameter setup function. Therefore, multi-statement code won't work in this spot. Instead, if the process of building the parameter value doesn't fit neatly into a single expression, you can hide the code in a function which returns the desired object, and call that from the parameter's text box.
I'm just picking up om.next and have run into a situation where I've got some form inputs realized as components which hold on to local state, e.g. validation state, actual input value, etc--this state is updated and accessed via om.next/update-state! and om.next/get-state. The trouble with this seems to be when I wrap the inputs in a form in a parent component I'm unsure how to get the state held by the input components. Is it better to pass along the parent component as a property of the input component? What about situations where there is no parent component?
It seems to me that there are 2 options for the use case you want to achieve:
pass the parent component as an argument as you said
have an entry in the global app-state that represents the current form being edited, which you can update via transact! irregardless of the component corresponding to the input. This way every component that represents an input knows where in the app-state to update itself (which key in the current form) — probably captured succintly in one mutation function.
1) is probably the easiest to implement given the code you have currently, but I always like to go for 2) because it doesn't deviate from the "single source of truth" opinion that Om Next recommends (and tries to enforce). Form data is in fact business data, which might not be desirable to have scattered in components. Testability is just one advantage that I immediately see from such approach.
In the implementation of a flow models that function with Modelica Standard Library DynamicPipe (or a similar model that builds from PartialTwoPortFlow) there are examples of flow models that take place in an environment with heat transfer that requires wall properties (e.g., heatPorts.T and/or heatPorts.Q_flow) in order to calculate the pressure drop.
For example, a pressure drop model may need to calculate a new visocisty or Prandtl number based on the medium pressure and the wall temperature to capture cooling/heating effects, etc.
The heat transfer model obtains properties of the medium via passing the "states" however there is no existing connection in DynamicPipe or PartialTwoPortFlow that goes the other way.
I've tried numerous variations of ideas and have had no success, including creating a new PartialTwoPortFlow that contains all the heat transfer calls that exist in DynamicPipe.
I hesitate to post this question as I am surprised I am having so much difficulty with this and would not be surprised to find a straight forward solution. Nevertheless I need this ability and curious if others have already solved this issue as I am running short on ideas.
So my questions is:
What is a proper/efficient means of passing the heatPorts.T values to the flowModel?
For those familiar with the MSL Fluids library and more specifically the Pipe models provided, this answer should (hopefully) make sense.
Aside:
It seems the dynamic pipe could be improved a little bit by not restricting the heat transfer area to the perimeter x lengths and instead introduce a parameter (e.g., heatTransferArea) that would permit the user to define it and default to perimeter x lengths. See below
parameter SI.Area heatTransferArea = perimeter*lengths "Total heat transfer area";
HeatTransfer heatTransfer(
...
final surfaceAreas=heatTransferArea , //perimeter*lengths <- replaced
...
End Aside:
In order to communicate heatPorts.T to the flowModel and to not have errors when I checked each of the models I had to do the following:
Make an "input" in the flowModel for Ts_w. Not parameter (take a look at how mediums.state is passed)! Might have to do some finagling with it like "diameters" (see DetailedPipeFlow) to make it be used how you think it's going to be used.
Duplicate PartialTwoPortFlow and add the final Ts_w = Ts_wFM to flowModel. Additionally define the variable SI.Temperature[nFM+1] Ts_wFM in PartialTwoPortFlow and establish definitions similar to statesFM in the equation section.
This will require adding a HeatPorts model to be added.
Duplicate DynamicPipe and change the extension to the new PartialTwoPortFlow. Set use_HeatTransfer to true (as I've set it up this has to be true now for this to work which isn't ideal but manageable). Might be good to make it a final parameter so it can't be changed.
Don't forget to connect heatPorts to the heatports added in step 2.
I believe that this capture a quick version of how I was able to get the wall temperature passed to the flowModel. Perhaps there is a more elegant way but I though this was pretty serviceable. I now simply have one more Partial model and one more pipe model called PartialTwoPort_wTemp and GenericDynamicPipe (I also incorporated my surfaceArea correction in the new pipe).
I would like to present the user with a variable number of scenes within the GUI (arranged say horizontally) composing different views of the data, depending on runtime conditions?
I really don't want to redefine the GUI, and a number of scene related traits for every use case. (i.e. bool_scene_1_viewable=Bool(), bool_scene_2_viewable=Bool()... )
It looks like I might be able to define a wildcard trait: scene_=Instance(Scene,()). But, if this is the best way to do it, how would I go about combining n traits into a View?
(A) I did not distinguish between "runtime" dependence, and merely depending on some number of traits that are declared after initialization (but before config_traits is called). As such, I can use default_traits_view to create a view that depends on the current state of the object and its members.
(B) I was also confused about how to turn this list_of_scenes into an object that could be viewed. After all, HGroup and VGroup don't take lists! I was missing that * could be used to unpack the list.
Steps:
1. init class instance
foo=Foo()
add scenes as you like
foo.add_trait(string_scene_name,scene)
foo.scene_name_list.append(string_scene_name)
foo.scene_list.append(scene)
Create group within default_traits_view()
items=[Item(name,style='custom') for name in self. scene_name_list]
scene_group=Group( *items)
I'm trying to use layers to make sure I separate everything into it's correct areas in my Swift / iOS / Xcode 6 project. The question, ultimately, is: is it OK / a common practice to move commonly used presentation-level logic to a separate presentation helper class instead of writing it over and over in multiple view controllers with little or no difference?
Here is an example to tie this in and give context:
One of the things I am aiming to do is use a UITableView to display report data. This UITableView will contain 7-10 rows, depending upon the user's preferences (nsuserdefaults). Each row contains a localized string for a label, and some decimal value.
As an example one row could be "Sales made this week: $500.00"
I have a reporting service class that's responsible for talking to the database and getting back / instantiating a report object. This report object contains the raw data for the report, i.e. how much you made this week, this month, this year, etc. Whether the user wants to show all these values or not is irrelevant to the service - it simply gets everything.
So since I have 3 view models that use this same report, I thought it would be wrong to rewrite the same code each time that checks the user's preferences, then creates/binds an array to the UITable and matches the labels with the report values from the object returned by the service.
A better way, I thought, was to create a presentation-level helper class whose job would be to take a report object (the thing I mentioned before that contains the report values), take a user's preferences, and then more generically combine them to create a list of localized strings matched with their respective report values, agnostic to what the view controller wants. Maybe if that requirement changes later (where different view controllers need more customization) I could use flags or different function names within that class.
This way all I have to do is something like
var report = ReportHelper.GenerateReport(reportData, userSettings)
and now report would be an object that could look like this (mock JSON data):
{"Amount made this week":"$100", "Amount made this month":"$500", "Amount made this year": "$10,000"}
And I can use this in any view controller.
The alternate is to just hard code those above values (obviously still pulling localized strings) but I don't know if I adding all those strings + checks based on user preferences + formatting. Seems more elegant to move it away.
Thanks!
I know too little about your problem to provide the definite answer, but basically you have 2 options:
- inheritance
- composition
I personally like inheritance although it is often stated you should choose composition over inheritance.
Your helper sounds somewhat like composition, so that would be the preferred setup. With your specific problem as I understand it, inheritance would lead to a duplication of data, so that is one more argument to choose composition.
So all in all you seem to be about right
Edit:
Inheritance is an "is" relationship, whereas composition is a "has" relationship.
See http://en.wikipedia.org/wiki/Object_composition for more details about composition.
And see http://en.wikipedia.org/wiki/Composition_over_inheritance for more info why and when to choose composition