via MIDI controllers.
my idea is to link PureData to GH via UDP. why pure data? cause' i can relate data like GH to generate numeric relations (and link it to audio generation)
so far i got PD and Processing to talk, but i can't get to grasshopper.
i use this definitions to make pd and processing to talk http://ubaa.net/shared/processing/udp/ and this GHX to get the data to GH http://www.grasshopper3d.com/forum/attachment/download?id=2985220%3...
i got this data from this post but the GH definition doesn't work for me. i have tried LAN definitions and "the engine" as well but they both freeze, even if i send data thru processing or PD.
i have a lot of questions at this time
1.- why processing tells me that i am getting the data from diferent ports, while i'm using 6000?
2.- why in the UDP definition i get no data out, even if it should say something like "waiting fordata/port/etc.." that's defined in the C# capsule
3.- is there a direct way to get midi data (key and CC) to GH
i also tried to use firefly to get the data via COM port. i know you can do this trick in processing but i just don't know how.
well. if anyone could help me i would share the results here (since it's a magister, results shoud be very interesting)
UDP has allways been a unsolved issue on other posts. maybe we could work it out ;)
Thanks…
Added by jota aldunce at 8:43am on September 28, 2010
giornata inaugurale sarà dedicata alla free-lecture introduttiva finalizzata alla realizzazione di un modello d'architettura complesso attraverso l'utilizzo di comandi e tecniche avanzate di rappresentazione con Grasshopper (plug-in parametrica di Rhinoceros) e 3dsMax. Sarà illustrato inoltre il potenziale di V-ray per 3dsMax realizzando un rendering concettuale. Durante il mini-corso dell' openDAY verranno mostrate le caratteristiche e le potenzialità degli strumenti per far luce sui nuovi valori assunti dalla modellazione 3D. La modellazione 3D sta interessando un pubblico sempre più vasto inserendosi in una nuova fase di ampia disponibilità per conoscenze, software, hardware di prototipazione e modelli. Pur mantenendo tutti i suoi valori già noti la questione si è talmente ampliata fino ad interessare norme giuridiche (diritti sui modelli ,concorrenza con offerte di servizi apparentemente simili, informazioni deformate e onfusione nei media) Makers University[http://www.makersuniversity.com], in collaborazione con parametricart, vi propone un punto di vista ampio e sintetico su queste tematiche.
Al termine della free-lecture, sarà illustrata l'offerta formativa [CLICCA QUI] di parametricart riferita ai corsi che si terranno nei mesi di Gennaio e Febbraio 2013 inseriti all'interno della più ampia programmazione della Makers University. SONO PREVISTE TARIFFE PROMOZIONALI PER COLORO CHE SI ISCRIVERANNO AI CORSI durante l'OpenDAY.
La lezione e la presentazione si terranno nel nuovo spazio co-working il PEDONE.
PROGRAMMAZIONE
- I temi della Makers University [Leo Sorge];
- Modellazione della parametricTower (concept di architettura complessa) utilizzando Grasshopper, applicativo per la modellazione parametrica [VIDEO] [Michele Calvano];
- Modellazione di una copertura reticolare 3D a completamento della parametricTower con 3dsMax utilizzando tecniche di modellazione mesh complesse [Wissam Wahbeh];
- Rendering con V-ray per 3dsMax illustrando la nuova interfaccia nodale [Wissam Wahbeh].
- Question Time per chiarimenti sugli argomenti illustrati.
COME
L'openDAY sarà aperto a tutti gli interessati,completamente gratuito e sarà replicato in tre sessioni di uguali contenuti organizzate nei seguenti orari:
Sessione [1] 11,30 - 13,30
Sessione [2] 15,30 - 17,30
Sessione [3] 17,30 - 19,30
Per necessità di organizzazione è importante la prenotazione all'evento utilizzando il form in fondo alla pagina specificando nella stringa apposita, il nome dell'evento e la sessione (es. open day sessione 1) oltre agli altri dati richiesti.…
arq, que se celebrará entre el 28 de Enero y el 1 de Febrero de 2013 en el Colegio de Arquitectos de Granada.
El taller está destinado a arquitectos, artistas y diseñadores, tanto como profesionales, como estudiantes de grado y posgrado, que, sin necesidad de haber tenido ningún contacto previo con entornos de programación o herramientas informáticas de dibujo paramétrico o generativo, están interesados en probar y experimentar con las opciones que nos pueden ofrecer a los diseñadores.
El taller está dividido en tres bloques:
Curso intensivo: del 28 de Enero al 30 de Febrero, en horario de mañana, de 10 a 14. Taller de proyectos: del 28 de Enero al 30 de Febrero, por la tarde, de 16 a 20; y el 31 de Febrero, durante todo el día.
Presentaciones: viernes 1 de Febrero, mañana y tarde.
Utilizaremos Grasshopper, el editor algorítmico asociado al software de modelado tridimensional y dibujo Rhinoceros, por su facilidad de aprendizaje, al tratarse de un entorno gráfico, facilidad de adquisición, al ser gratuito y haber disponible una versión de prueba de Rhinoceros también gratuita, y amplia difusión en los últimos años. Y lo emplearemos tanto como modelador, como conector entre otros softwares y varias disciplinas. Por este motivo, también utilizaremos algunos de sus plug-ins, como Geco, para análisis ambiental, Elk, para enlazarlo con OpenStreetMap o Kangaroo, para simulación de sistemas físicos.
Lo único que necesitas es un ordenador portátil (si no pudieras conseguir), hacer el ingreso con el importe correspondiente y mandarnos tus datos y el recibo bancario del ingreso a smartlabgranada@gmail.com. Puedes ver los detalles en el apartado de Inscripción. El resto del material, tanto software como hardware, lo ponemos nosotros.
Nuestro acercamiento a estas herramientas es entusiasta acerca del potencial creativo que pueden ofrecer a diseñadores y artistas, pero también crítico y especulativo. Nos alejamos tanto de una posición puramente formalista, como del estricto funcionalismo, a los que desde los últimos años frecuentemente se ha asociado a esta disciplina.…
Added by Miguel Vidal at 8:42am on January 19, 2013
o está dirigido a estudiantes de arquitectura y diseño de interiores, recién titulados y profesionales interesados en el software o que necesiten conocer las herramientas básicas de las que dispone el programa en los diferentes ámbitos y cómo enfocarlas a arquitectura.
Descripción:El contenido del curso enseñará a utilizar el programa de diseño Rhinoceros 3D aplicando su metodología de trabajo en el campo de la arquitectura, básandose además de la creación de pequeños elementos paramétricos para controlar el diseño y acabar renderizando las geometrías 3d con V-Ray para Rhino.
El curso consta de 3 módulos de 12h de duración cada uno (que pueden realizarse juntos o por separado) en los cuales se profundizará en herramientas de Rhino, Grasshopper y V-Ray a medida que se realizan casos prácticos sobre proyectos arquitectónicos.Se pretende establecer un sistema de trabajo eficiente desde el inicio del modelado hasta la posterior creación de imágenes para documentación del proyecto.
Módulo Rhinoceros Arquitectura:• Conceptos básicos e interfaz de usuario Rhino• Introducción al sistema cartesiano en Rhino• Clases de complejidad de geometría• Importación/exportación de archivos compatibles• Topología NURBS• Trabajo con Sólidos• Estrategias básicas de Superficies• Introducción a Superficies Avanzadas
Módulo Grasshopper:• Conceptos básicos e interfaz de usuario Grasshopper• Introducción a parámetros base y componentes• Matemáticas y trigonometría como herramientas de diseño• Matemáticas aplicadas a creación de Geometría• Introducción a listas simples• Análisis de Superficies y Curvas• Dominios de Superficies y Curvas• Panelado de superficies• Manejo de listas y componentes relacionados• Modificación de panelados en función de atractores• Exportación/Importación de información a Grasshopper
Módulo V-Ray para Rhinoceros:• Conceptos básicos e interfaz de usuario V-Ray• Vistas guardadas• Materiales V-Ray• Materiales, creación y edición• Iluminación (Global Illumination, Sunlight, Lights)• Cámara Física vs Cámara default• Canales de Render• Postprocesado básico de canales
Detalles:Instructores: Alba Armengol Gasull y Oriol Carrasco (SMD Arquitectes)Idioma: CastellanoHorario: 22 JULIO al 26 JULIO 2013 // 10.00 – 14.00 / 16.00 – 20.00Organizadores: SMDLugar: SMD lab, c/Lepant 242 Local 11, 08013 Barcelona (map)
Software:Rhinoceros 5Grasshopper 0.9.00.56V-Ray 1.5 for RhinoAdobe Photoshop CS5Links de versiones de evaluación de los Softwares serán facilitadas a todos los asistentes. Se usará unica y exclusivamente la versión de Rhino para PC. Se ruega a los participantes traer su propio ordenador portátil.
Registro:Modalidad de precio reducido por tres módulos 275€Posibilidad de realizar módulos por separado 99€…
to incorporating math and geometry in computational design education, Paneling Tools
Marlo Ransdell, PhD Creative Director, at FSU , Digital Fabrication in Design Research and Education
Andy Payne, LIFT architects | Harvard GSD | FireFly
Jay H Song, Chair, Jewelry School of Design, Jewelry as Personal Expression, Extra+Ordinary@Jewelry.com
Pei- Jung (P.J.) Chen, Professor of Jewelry, SCAD
Gustavo Fontana, designer/co-founder nimbistand, Diseñar, desarrollar y comercializar productos por tu cuenta.
Joe Anand, CEO MecSoft Corporation, RhinoCAM
Julian Ossa, Chair, Industrial Design Director, Diseño – Una opción de vida a todo vapor!, UPB
Minche Mena, SHINE Architecture, Principal
J. Alstan Jakubiec, Daylighting and Environmental Performance in Architectural Design Solemma, LLC
Carlos Garnier R&D Director / Jaime Cadena – General Director, Plug Design, www.plugdesign.com.mx
Mario Nakov, www.chaosgroup.com [ V-Ray ]
Andres Gonzalez, RhinoFabStudio
Workshops:
o) Paneling Tools
o) RhinoCAM
o) Rhinology in Design, for Jewelry
o) Footwear
o) V-Ray: Jewelry Design
o) V-Ray: Architects and Industrial Designers
o) FireFly
o) J. Alstan Jakubiec, DIVA
The cost for each workshop or the Lectures is 95.0 US$
To register:
WORK-SHOPS April 2 - RHINO DAY
WORK-SHOPS April 3 - RHINO DAY
REGISTRATION RHINO DAY
NOTE: All students and faculty members that register to this event, will receive a Rhino 5 Educational License at the event.
…
you may know, PCS (from now I will call polar coordinate system with PCS, and cartesian one with CCS) describes point position with 2 values (like x and y in CCS) which are r and theta(r,theta). r is for distance from PCS center, theta is angular dimension which is in 0 to 360 or 0 to 2*pi domain.
To hark back to David's guide line - here it is replaced with guide circle.
Why to sort points like this ? As usual, one image tells more...
Here is logic behind all this stuff :
Find an average point of all given points*
Search for furthest point from an average point*
Create a circle with center at average point and radius = distance from average point to furthest point*
*Steps 1-3 can be replaced with custom hand-made circle, I decided to automate it that way.
For each point find closest point on circle - this will be used for finding theta value
For each point find distance to average point - this is r value
To overcome problem with same theta (t) values (like same x values in CCS), instead of multiplying by 1000, we will use a new create set component. This component creates set of integers, each one representing one unique input value. So if points A, B, C, D, E are (r,theta) :
A (1, 30)
B (2, 30)
C (3, 30)
D (1, 45)
E (1, 60)
Then create set will output list of integers = 0,0,0,1,2 (same theta for A, B, C other theta for D and E). Now its getting really easy - remap r values to domain 0 to 0.5 (or any less then 1), and add integers from create set component to remapped r values.
7. So what we have now is list of floating point numbers : A=0, B=0.25, C=0.5, D=1, E=2
Profit of remapping is that r values will never affect integers representing theta values - and all the information is stored in one floating point number ! By sorting these values we will obtain proper order of points - to complete this, we need to sort points parallel with values.
What's really cool about polar sorting - there could be any amount of points, but polyline connecting all of them will never self-intersect. Probably there is some relation with 2d convex hull.…
east make all our algorithms thread-safe, so they can all be called from multiple threads, this is the first step towards multi-threading.
But multi-threading is not just something you switch on or off, it's an approach. Let's take the meshing of Breps for example. Let's assume that at some point one or more breps are added to the document. The wireframes of these breps can be drawn immediately, but the shading meshes need to be calculated first. How do we go about doing this? Allow me to enumerate some obvious solutions:
We put everything on hold and compute all meshes, one at a time. Then, when we're done we'll yield control back to the Rhino window so that key presses and mouse events can once again be processed. This is the simplest of all solutions and also the worst from the users point of view.
We allow the views to be redrawn, mouse events and key presses to be handled, but we perform the meshing in a background thread. I.e. whatever processor cycles are left over from regular use are now put to work on computing meshes. Once we're done computing these meshes we can start drawing the shaded breps. This is a lot better as it doesn't block the UI, but it also means that for a while (potentially a very long time) our breps will not be shaded in the viewport. This approach is already a lot harder from a programming perspective because you now have multiple threads all with access to the same Breps in memory and you need to make sure that they don't start to perform conflicting operations. Rhino already does this (and has been doing for a long time) on a lot of commands, otherwise you wouldn't be able to abort meshing/intersections/booleans etc. with an Escape press.
So we can compute the meshes on the UI-thread or on a background thread. How about using our multiple cores to speed up the process? Again, there are several ways in which this can be achieved:
Say we have a quad-core machine, i.e. four processors at our disposal. We could choose to assign the meshing of the first brep to the first processor, the second brep to the second processor, the third brep to the third processor and so on. Once a processor is done with the meshing of a specific brep, we'll give it the next brep to mesh until we're done meshing all the breps. This is a good solution when multiple breps need to be meshed at once, but it doesn't help at all if we only need to compute the mesh for a single brep, which is of course a very common case in Rhino.
To go a level deeper, we need to start adding multi-threading to the mesher itself. Let's say that the mesher is set up in such a way that it will assign each face of the brep to a new core, then -once all faces have been meshed- it will stitch together the partial meshes into a single large mesh. Now we've sped up the meshing of breps with multiple faces, but not individual surfaces.
We can of course go deeper still. Perhaps there is some operation that is repeated over and over during the meshing of a single face. We could also choose to multi-thread this operation, thus speeding up the meshing of all surfaces and breps.
All of the above approaches are possible, some are very difficult, some are actually not possible if we're not allowed to break the SDK. A further problem is that there's overhead involved with multi-threading. Very few operations will actually become 4 times faster if you distribute the work across 4 cores. Often one core will simply take longer than the other 3, often the partial results need to be aggregated which takes additional cycles and/or memory. What this means is that if you were to apply all of the above methods (multi-thread the meshing of individual faces, multi-thread the meshing of breps with multiple faces and multi-thread the meshing of multiple breps) you're probably worse off than you were before.
--
David Rutten
david@mcneel.com
Poprad, Slovakia
* an example would be the z-sorting of objects in viewport prior to repainting, which is a step performed on every redraw as far as I know.…
- nickname is rather the best approach - and not on active group, but that's irrelevant anyway).
Step back (assuming that you are talking about the "Tens_from_random_blah_blah" definition):
1. Engineering is the art of demystifying (or we are promising that anyway, he he). This means that you start defining (better: outlining) some topology for things based on some "generic" rules (like the ones applied for the masts,cables,cones etc etc). These things are kept in some kind of structure (Lists, DataTrees etc). Things are few in 99.99999% of cases (i.e. : even the biggest membrane "module" has, say, 20-50 masts per "module").
2. Then ... handling things "individually" (mostly modifying) becomes the most critical part. See this (an x "possible" solution by combining a myriad of "options" : a no cones membrane solution, in plain English):
3. But the above is impossible (for more than obvious reasons). You should deploy masts in some high/low sequence in order to achieve some meaningful convex/concave formation that could work.
4. This "works" : 5. This doesn't:
6. This works partially (the formation at the back is "flat" == undo able):
7. This is utterly kitsch (and faulty as the case6 - the back portion):
So it's quite obvious that without a (quite complex) capability to individually control things (in this occasion : mast heights) the whole definition is a waste of computer time. Additionally the more the solution is "demystified" (some curve is defined, some random points are created, some masts are in place, some cables appear etc etc) the more additional constrains are required in order to "narrow" the possibilities (In plain English : sliders should control other sliders as regards their min/max values, true/false, you/me etc etc).
Remember that we are talking about ONE (mast height) out of a myriad things that you should control "manually" (it's utterly pointless to mastermind some kind of "generic" rules - or use naive attractors etc etc) .You'll see the difference when I'll completely reform the definition by adding individual control upon anything.
PS: what about the blocks? (the real life stuff that actually make any solution possible). Can you imagine a 2nd set of "restrictions" imposed by "a child to his parent"? (Assembly/Component modeling , that is).
more soon
…
the results myself and I am open to changing the name/description of the input based on what you have found here. modulateFlowOrTemp is not the best name for what seems to be going on and we should change it to reflect more what is happening in the IDF.
Here is how I am understanding the results of the different cases:
1) When the variable flow option is selected (and the outdoor air set to "None"), the heating and cooling of the space seems to happen only through re-circulation of the indoor air. My comparison to a VAV system was not appropriate and perhaps it would be better to compare it to a window air conditioner or a warm air furnace, which, as far as I understand, only re-circulate indoor air and do not bring in outside air.
2) My reasoning for the name modulateFlowOrTemp came mostly from my realization that the supply air temperature remained within the defined limits when the variable flow option is selected (and the outdoor air set to "None"). When the outdoor air was set to Maximum or Sum, the supply air temperature went way out of the temperature limits that I initially set. I realize now that the flows are varying in both cases and the name of the input really must change.
3) I think that the reason why we don't see any effect from the air side economizer is because the heating/cooling energy results that you get from an ideal air system are just the sum of the sensible and the latent heat added/removed from the zone by the system. This value of heat added or removed from the zone does not change whether the added/removed heat comes from outside air or from a cooling/heating coil. Since there is no cooling coil or boiler or chiller in an ideal air system, there is no way to request an output of the energy added/removed by such a coil or chiller as opposed to that removed/added by outside air. In other words, the air side economizer option on the ideal air system is practically useless because it does not help us differentiate the cooling that comes from the outside air vs. that which comes from a coil. All that it does is change the outdoor air fraction while keeping the reported cooling/heating values the same.
Please let me know if you think that this explanation makes sense, Burin and, in light of all this, I am very interested in your suggestions.
From my own perspective, I am now convinced that the default should definitely have the outside air requirements set to "None" since, otherwise, we cannot distinguish cooling/heating that happens from addition of outside air and that which must be supplied by a coil. At least when we get rid of the outside air requirement, we can be sure that the ideal air system values are only showing heating/cooling from a coil or HVAC system.
I have decided to remove the airsideEconomizer input since it seems to give misleading expectations. I am going to recommend here on out that, if you want to estimate the effect of increasing outside air on cooling, you should use the "Set EP Airflow" component, use fan-driven natural ventilation, and you should connect a custom CSV schedule of airflow. You will have to create such a schedule with native GH components using the outside air temperature, your zone setpoints, and the times that you are cooling in your initial run of E+. Either you do this or you set up a full-blown system with OpenStudio.
I have also decided to get rid of the heatRecovery input since it seems like this will also produce misleading expectations by the same logic.
Lastly, I am going to change the name of the modulateFlowOrTemp_ input to outdoorAirReq_. The default will be to have no indoor air requirement as stated above but you can input either "maximum" or "sum" to have the IDF run accordingly.
Let me know if this sounds good or if you have suggestions. Updated GH file attached. The github has the new Ideal Air Loads component. Make sure that you have sync correctly and restart GH after updating your components.
-Chris…
e current data should be turned to be original data, is that right?there are 3 cases.
what do this components effect the performance after if i turn the component to be flatten and graft and to connect to other component?
{, is that0}
{0;0}
{0;0;0}
{0;0;0;0}
{0;0;0;0;0}
{0;0;0;0;0;0}…